Re: Environment variables, debian/rules and dpkg-buildpackage
On Mon, Mar 16 2009, Raphael Hertzog wrote:
> On Mon, 16 Mar 2009, Manoj Srivastava wrote:
>> > 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).
>> We do not want to override *EVERYTHING* in the Makefile, just
>> the CFLAGS. This blunt instrument of the -e flag is not a good
> Then he can add the required parameter on the command line instead
> of using the environment.
> make -f debian/rules CFLAGS="..." <target>
> You don't seem to grasp the fact that mandating some variables to be
> preset doesn't forbid us to rely on Makefile features if we chose to.
Heh. I never thought I would be lectured on the use of make. Cute.
And you are missing the point that making people type stuff on
the command line for site specific stuff looses out to being able to
edit a conffile instead.
dpkg might suffice if we were not wanting the ability to set
site wide build defaults a la gentoo use flags -- but it seems silly to
give up on that i we are designing a solution now.
>> > 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)
>> Err, I think you need to get more conversant with Make. Yes,
>> there is no way to know whether or not the environment variables were
>> set by dpkg or the user; but it is itrivial to make it so that the
>> project wide defaults can be overridden by the site wide stuff, and
>> each being overridden by the package at will. We can even make it so
>> that the package can tell which one set the value, and override only
>> the project wide one and not the site variable.
> It is trivial to do with whatever solution we retain. The problematic part
> that I pointed out is "how to know in the rules file if the CFLAGS value
> comes from the command-line, from the environment or from the makefile
> Do you have a solution to that ? If no, then there was no point in
Of course I do.
> suggesting me to get more conversant with Make. If yes, show it to
File: make.info, Node: Origin Function, Next: Flavor Function, Prev:
Eval Function, Up: Functions
This is precisely what the origin function is for.
Also, you might not need it with the snippet example:
default_foo := BAR
site_foo := baz # by default, this is empty -- set by site admin
ifndef (,$(strip $(site_foo)))
foo = $(site_foo)
foo = $(default_foo)
Now the variable foo is set, but we can tell it was set in a
makefile, and set by default or the site admin. And make a decision in
the rules file based on that. (Note the use of := versus = above; the
difference is significant, really).
We can also tell if a variable was set in the environment, or
the command line -- but the whole include makefile snippet means we do
not have to replicate what dpkg does on the command line if we do not
want to use that single point of entry.
> Suppose you have "FOO ?= bar" in the Makefile, write me the rest of the
> Makefile so that I have this:
> $ FOO=foo make
> FOO was set in the environment
> $ make FOO=foo
> FOO was set on the command-line
> $ make
> FOO was set in the Makefile
The world is coming to an end ... SAVE YOUR BUFFERS!!!
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C