+++ Stephen Kitt [2011-04-24 19:14 +0200]: > > So I would be opposed to making such a change in policy for the time being; > > I think cross-compilers should stick with the traditional cross-compiler > > directories and stay away from the multiarch directories until we have more > > practical experience with multiarch under our belts and can make some > > educated decisions about how we want this to all fit together. > > OK.
I expect the multiarch paths to replace the 'traditional cross-compiling' paths in due course for all target architectures, including ones that aren't Debian-suported (i.e currently mingw-whatever-you-call-it, avr32, msp430), for both native use and cross-compiling. Steve will have to explain to me why we might want to use different paths for non-self-hosting arches. It seems to me that having one canonical place to look for arch-dependent files is good whether you want them for running or for (cross-)building. But we do need to proceed carefully in order to get this right, and the cross-only arches are a little way down our list of issues :-) I'd be interested to hear how you currently do things in mingw world (and more importantly what things you want to be able to do) so that we can take your needs into account. I do think that getting the 'win32' arch name and triplet defined in dpkg-architecture is stage 1 for you. I thought we'd already done that years ago, when this last came up, but obviously not. dpkg-architecture already supports 269 options including such not-very-useful combinations as uclibc-linux-s390 and solaris-alpha, so it really ought to know about the win32 and win64 ABIs. It's generally a very simple patch to a few tables in dpkg to add a new arch. Having the mappings between Debian arch name, gnu triplet and multiarch path all in one place is vital to making all this stuff work properly. Please make sure you get the names right - changing them later will be very painful. A multiarch name signifies an ABI, as explained in more detail here: http://wiki.debian.org/Multiarch/Tuples (note that that proposal is no longer current, but does explain what a multiarch ABI name is and isn't). > Would it make any sense then to add an exception for traditional > cross-compiler directories, or should cross-compiling library packages simply > continue using lintian overrides? So you ship packages pre-built to install to the traditional cross-compiler dirs (as opposed to making them with dpkg-cross as we do on arches where native packages are shipped). Makes sense. I think that packages installing to those paths should continue using lintian overrides as they are very much 'non-standard'. > One last question: without considering multiarch, what is the situation > regarding headers? Is the proposal in http://bugs.debian.org/542865 still the > intended approach, or is there another solution? Headers are deliberately excluded from the scope of https://wiki.ubuntu.com/MultiarchSpec in order to shink the problem space down into something that it would only take 6 years to implmenet :-) However the extra bits for cross-compiling using multiarch paths are detailed here: https://wiki.ubuntu.com/MultiarchCross and we are already implementing that stuff. Arch-dependent headers will go into /usr/include/<multiarchpath> and arch independent headers will stay in /usr/include. We can also just put all headers in /usr/include/<multiarchpath>, and have duplication (as we already do for the traditional paths) if the above is problematic, however it seems to be working fine for the few packages changed so far, so spliting the arch-dependent ones out seems like the way to go. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20110424214640.ga20...@dream.aleph1.co.uk
