On Sat, 11 May 2013 11:39:28 +0200, Goswin von Brederlow <goswin-...@web.de> wrote: > On Wed, May 08, 2013 at 11:57:58AM +0200, Stephen Kitt wrote: > > 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.
Yes, but that's not the problem. Take the premise that the target directory structure is as described above, so most library development packages ship as many headers as possible in /usr/include. For now we'll assume all mingw-w64-...-dev headers are in /usr/include/...-w64-mingw32; but to use mingw-targeted libraries other than mingw-w64-...-dev (libgtk for example), the mingw toolchain needs to look in /usr/include as well. This is all fine as long as libc6-dev is not installed (say perhaps with sbuild and cross-build-essential). But in a typical work environment, libc6-dev will be installed, and because we'll always be cross-compiling on the buildds, packages which need to build stuff for the host to run during the build (wine-gecko does this) need build-essential too, so libc6-dev headers end up in /usr/include and are picked up by the mingw toolchain. Likewise for other -dev packages which may be available for the host architecture but not the target architecture. Imagine the confusion then for configure scripts! As far as I can see there are three solutions to this: * split headers completely * drop the idea of building mingw packages using the existing Debian packaging * add patches to all supported packages so that they build differently when targeting mingw (and any other partial architecture which can't share /usr/include) Fedora went with the second solution; they have mingw-specific packages for everything they build targeting Windows. If we could build-depend on source packages (which has been mentioned elsewhere in this thread) this would be possible on Debian too, although it would be a bit of a chore for me (and whoever else wants to chip in). But I wouldn't want supporting a non-free operating system to become a chore for more Debian developers than necessary! (The aim of all the mingw work as far as Debian is concerned, apart from providing a nice mingw build environment, is to provide a wine-mono package, which needs a whole bunch of dependencies. wine-gecko is relatively easy to support because it's essentially Firefox, which ships all its build dependencies in its source archives.) Regards, Stephen
signature.asc
Description: PGP signature
