Re: Cross-compiling for Win32

[Ron <ron@debian.org>]

Hi,

> > Volker Grabsch writes:
> Another solution would be a big package like "mingw32-libs" which
> is arch-independent and contains many small libraries for use
> with the cross compiler of the existing Debian package "mingw32".
> This solution wouldn't use any dpkg-cross mechanism, and it would
> be much simpler.

This sounds like two separate things to me, you don't have to put
everything in one big package to 'natively' install them in arch
specific dirs, but that does require support from within the package
itself to build cross variants.  This is how the wx-cross packages
work, and I believe (more or less) how Simon has done his uclibc
package.  This can be a useful idiom for targets that have no existing
Debian packages that would simply need their binaries relocated for
cross builds.

But aggregating everything in one package makes it much less efficient
to update single parts of it later.


> In fact, this would be the same spirit as the
> "mingw32" package which is also a "big" package that corrensponds
> to many small "normal" Debian packages (gcc, g++, binutils, libc, ...).

That's not really why the mingw package used to do this (and it does it
much less now than it used to).  Back in the dreamtime mingw's ancestors
would build most reliably with all the gnu tools aggregated into a
single source tree.  Trying to build the toolchain components individually
was both more complicated and more likely to fail.

That latter point has not been true for some time now, and in fact the
reverse is true.  We still aggregate the runtime and win32api packages,
mainly since they are somewhat codependent and there is not much to gain
but pain in updating one without the other, and we still aggregate gcc
and g++, for more or less the same reason, with binutils in its own
separate package to make up the triumvirate.

This grouping has proved fairly robust.  The arch-all runtime package
only needs to be built once, then the normal Debian buildd's can
bootstrap the rest of the toolchain, even on brand new archs, while
the binutils and compiler can also be updated separately, since they
aren't always released together upstream anymore anyhow.

But I don't think that really fits into the 'big package' idiom you
describe, so I wouldn't use it as a precedent or sign of best practice.

hth!
Ron