Re: jessie release goals
On Wed, May 08, 2013 at 11:57:58AM +0200, Stephen Kitt wrote:
> Let me explain where I'm coming from... With MinGW-w64, we have a set of
> compilers, headers and libraries which allow building software targeting
> native Windows, without Cygwin or much in the way of wrappers at all. This is
> definitely non-POSIX and not much like Debian; but I imagine similar problems
> crop up when targeting a different libc. Despite the differences, and thanks
> to a lot of work by upstream developers, a lot of the libraries in Debian
> build fine when targeting Windows, and most of the time the only change
> required is to pass the correct target triplet to the configure script. This
> makes it sorely tempting to add mingw (i386, amd64 and arm as Dmitrijs
> mentions) as partial architectures in Debian and use all the existing
> packaging as much as possible to provide at least -dev packages and DLLs for
> as many libraries as possible; this would greatly simplify the lives of
> people working on building stuff for Windows (currently they basically have
> to produce Makefiles which build all their dependencies - and then you end up
> with things like the Firefox source packages which include all their
> dependencies on all platforms).
>
> The big issue which crops up then isn't so much the directory structure's
> impact on the build process, but rather its impact on the packaging process.
> If the target directory structure depends on whether we're building for a
> full Debian architecture or for a partial architecture or just some
> cross-compiler target, that means ad-hoc changes in the packaging for the
> various cases and that much more friction (see for example
> http://bugs.debian.org/671437 - although in zlib's case packaging changes are
> necessary to build for Windows).
But it wouldn't. The target directory structure would be the same
across all builds. It would always be
/usr/include/[$(DEB_HOST_MULTIARCH)] and
/usr/lib/[$(DEB_HOST_MULTIARCH)].
The effect of partial architecture is simply that not everything needs
to be build for that architecture and the partial architecture might
not be self hosting. E.g. we can cross build for mingw but we wouldn't
be including windows in Debian nor run a buildd on windows.
> I know (2) is well-tested, and it reduces duplication drastically. Does this
> outweigh being able to use multiarch and Debian's existing packaging work as
> a generic means of supporting cross-compilers?
>
> > > we could support cross-compiling to anything with the same
> > > structure - I'm thinking MinGW-w64 here of course, but I imagine it would
> > > apply to other targets too, some of which are supported in Debian already
> > > using the /usr/triplet/include directories.
> >
> > The header-layout issue is independent of the need for dpkg-architecture to
> > know about an arch to use multiarch mechanisms for cross-building to it. But
> > that's very easy to do (An easy way to add arches in a local config
> > file is something that's been mentioned before). Having mingw as an
> > arch is a good idea if it isn't already.
> >
> > And you can still use a sysroot and non-multiarch ways of filling it
> > if you prefer. I haven't really experimented with multiarch and
> > sysroot at the same time but SFAICS it should work.
>
> Indeed, but when I first saw multiarch I couldn't help but think this was a
> really nice way to support cross-compilation too; at the time I was told it
> was too early to consider that, it would appear now is the right time before
> things become set in stone.
>
> Unless I'm mistaken, if we go down the (2) route we could still have a mingw
> (partial) architecture, but every single package we'd want to build on it
> would need to handle it specifically...
>
> Regards,
>
> Stephen
I think you are mistaken. mingw should handle just like any other
architecture. Only difference being that you can't build natively, you
have to cross-build. But let us know if you tried it.
MfG
Goswin
Reply to: