On Fri, Apr 08, 2011 at 09:51:03PM +0200, Bill Allombert wrote: > I already made this comment, but I strongly think it should be normative. > Specifically we should mandate that:
> 1) /usr/include/<triplet> be added to the default hearder search path of > <triplet>-gcc. It seems strange to me that we would mandate something in policy that affects approximately one package (the compiler). However, I think this is unquestionably the correct thing for the compiler to do, so if there's general agreement that it belongs in policy I'll happily second. > 2) Packages that would install headers in /usr/include/path install them > in /usr/include/<triplet>/path This is too strong a requirement. The majority of headers can still be installed to /usr/include/path because they're invariant between architectures. It's only when a header needs to contain different contents between different architectures that /usr/include/<triplet> must be used. Where possible, I think packages should leave their headers directly under /usr/include, because: - it reduces duplication of data on disk (but headers are small compared to libraries, so this isn't a huge deal) - while it's bad form to depend on specific filesystem paths for headers rather than using the compiler include path, there are plenty of packages in the archive whose build systems are bad form. We're in uncharted waters here, and I don't think we should make ourselves more incompatible with existing software than is strictly necessary. > Requiring the user to pass -I to the compiler should be discouraged. Note that this "discouragement" is in conflict with the upstream behavior of a number of libraries, including much of the GNOME stack which uses pkg-config as an interface to declare additional -I arguments. So I'm not convinced putting this in policy adds much value. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
