On Mon, 16 Mar 2009, Bdale Garbee wrote: > > > I think he ment that you can not know wether the setting comes from > > dpkg-buildpackage or the user. If it comes from dpkg-buildpackage then > > debian/rules should be free to override it as needed. If it comes from > > the user then that is another story. At least that is my take on it. > > This is a great point. It must be possible to craft a rules file that > overrides > system or distribution wide defaults and which can be over-ridden by an > individual > building the package.
I don't see why it's needed, it's the job of the rules file to adjust the flags if there's a reason to deviate (like using -O0 instead of -O2 for some arch with compiler problems) but in general the package should not override completely the default flags but just complete them and/or adjust/fix them if needed. However, if the caller really wish that his build options prevail in all cases, he can use "make -e" (and dpkg-buildpackage has the -R option that let him call "debian/rules" as "make -e -f debian/rules" instead). If necessary we can add a new option --force-flags to dpkg-bp or similar to make this even easier. > That seems to require the ability for the code in a rules file to > distinguish between things in the environment because they're defaults > and things in the environment that are attempting to override defaults. Apparently there's no way to know from where the variable value come in make. That's true for environment variables like for command line variables. (at least according to my lookup of info make) So if we really want the rules files to be able to know, we have to add yet another requirement to create this information. This is not desirable IMO. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
