On Mon, May 13, 2013 at 07:26:15PM +0200, Stephen Kitt wrote: > 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.
Every compile has to look in /usr/inlclude/triplet and /usr/include/. mingw is no special case there. > 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. Only architecture independent header are in /usr/include. Now in the case of w32/w64 as architectures those headers must also be suitable for windows or they are no longer architecture independent. I guess that is the problem you see. I don't see that anything changes for the layout. You just added a rather strange arch which breaks the architecture independency of libc6-dev stuff. Is that any different from building for a uclibc system? I think you have the same problem there. How much of libc6-dev and other libs are we talking about here? Packages could also have: foo-dev-common:all (or all foo-dev): /usr/include/foo.h foo-dev:w32: /usr/include/w32/foo.h -> ../foo.h foo-dev:w64: /usr/include/w64/foo.h -> ../foo.h Then mingw would only need to look there. This would be special casing those archs. So not an ideal solution. > 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! Yes, that is a big problem. Luckily we have Build-Depends/Conflicts so all the right packages are there and all the wrong packages are not. For buildds that shouldn't be a problem. Also any link test for libs will fail if the -dev is not installed for the right arch. > As far as I can see there are three solutions to this: > * split headers completely Possible without any toolchain changes. Just move the files in every -dev package. > * drop the idea of building mingw packages using the existing Debian > packaging I don't think mingw is overly special there. Cross-compiling, esspecially for a different libc, will be verry similar. > * 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) * install w32/w64 packages in a sysroot, i.e. prefix every file on unpack. Not sure how well that would work with maintainer scripts though. For other cross-compiles one can use chroot but you probably don't want / can't use that for w32/w64. This could be done during build. Sort of like option 3. A small patch to move debian/package/* to debian/package/usr/lib/mingw/ before building the deb. > 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 MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130514144935.GK27079@frosties