Problem with implicit rule for .o files and overriding of CXXFLAGS.

[Charles Plessy-12]

Dear mentors,

while working on an update to the `proda' package, I realised that a
compilation option, DVERSION="\"1.00\"", was discarded during the build
of the Debian binary package. The reason is very simple:

OTHERFLAGS = -DVERSION="\"1.00\""
CXXFLAGS = -g -W -Wall -pedantic $(OTHERFLAGS)

proda : $(OBJECTS)
        $(CXX) $(CXXFLAGS) -lm $(OBJECTS) -o proda

The Debian build system overrides CXXFLAGS and $(OTHERFLAGS) is never
passed to the compiler.

First of all, I would appreciate if somebody could give me a link to an
authoritative documentation that explains that CXXFLAGS (and others)
should be expected to be changed to local values by the user. It seems
to me that many upstream authors ignore this fact and write makefiles
that will not work well if CXXFLAGS is changed to the Debian standard
values. (In exchange for the link, I will update
http://wiki.debian.org/GettingPackaged accordingly).

For Proda, I would like to submit a change upstream, such as something
like:

OTHERFLAGS = -DVERSION="\"1.00\""
CXXFLAGS = -g -W -Wall -pedantic

proda : $(OBJECTS)
        $(CXX) $(CXXFLAGS) $(OTHERFLAGS) -lm $(OBJECTS) -o proda

Unfortunately, $(OBJECTS) is a long list of .o files, each built by
implicit rules like:

foo.o: bar.h baz.h
toto.o : tata.h
anotherone.o : baz.h tutu.h
etc...

My problem is that I do not know the contents of the implicit rule
building the .o files from the .h files, nor how I can tell to make to
add $(OTHERFLAGS) to this implicite rule.

Any idea ?

Have a nice day,

--
Charles Plessy
Debian-Med packaging team
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Rudi Cilibrasi, Ph.D.]

>
> First of all, I would appreciate if somebody could give me a link to an
> authoritative documentation that explains that CXXFLAGS (and others)
> should be expected to be changed to local values by the user. It seems
> to me that many upstream authors ignore this fact and write makefiles
> that will not work well if CXXFLAGS is changed to the Debian standard
> values. (In exchange for the link, I will update
> http://wiki.debian.org/GettingPackaged accordingly).


Hi Charles,

http://www.gnu.org/software/automake/manual/make/Implicit-Rules.html#Implicit-Rules

I am curious what other DD's do. As for me, I usually try to save the
original "default" CFLAGS, CXXFLAGS, and LDFLAGS before I change them.
 Usually something like:
OLDCFLAGS=$(CFLAGS)
CFLAGS=-W...
then I can change CFLAGS however and use OLDCFLAGS to get the old
settings reliably.

Cheers,

Rudi

>
> For Proda, I would like to submit a change upstream, such as something
> like:
>
> OTHERFLAGS = -DVERSION="\"1.00\""
> CXXFLAGS = -g -W -Wall -pedantic
>
> proda : $(OBJECTS)
>        $(CXX) $(CXXFLAGS) $(OTHERFLAGS) -lm $(OBJECTS) -o proda
>
> Unfortunately, $(OBJECTS) is a long list of .o files, each built by
> implicit rules like:
>
> foo.o: bar.h baz.h
> toto.o : tata.h
> anotherone.o : baz.h tutu.h
> etc...
>
> My problem is that I do not know the contents of the implicit rule
> building the .o files from the .h files, nor how I can tell to make to
> add $(OTHERFLAGS) to this implicite rule.
>
> Any idea ?
>
> Have a nice day,
>
> --
> Charles Plessy
> Debian-Med packaging team
> Tsurumi, Kanagawa, Japan
>
>
> --
> To UNSUBSCRIBE, email to debian-med-REQUEST@...
> with a subject of "unsubscribe". Trouble? Contact listmaster@...
>
>

--
Git, Hg (Mercurial), and Subversion (svn) hosting over SSH
http://sshcontrol.com/


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Yavor Doganov-3]

В Wed, 25 Jun 2008 13:24:17 +0900, Charles Plessy написа:

[ I had not looked at the `proda' package, sorry. ]
 
> OTHERFLAGS = -DVERSION="\"1.00\""
> CXXFLAGS = -g -W -Wall -pedantic $(OTHERFLAGS)

Use CPPFLAGS for this -- of course the recipes should be properly written
in order to have some effect.

> The Debian build system overrides CXXFLAGS and $(OTHERFLAGS) is never
> passed to the compiler.

Yes and no, see '(make)Environment'.

If you define (or inherit from the environment) CXXFLAGS in debian/rules,
and you do in the build target `$(MAKE) CXXFLAGS="$(CXXFLAGS)"', and
upstream's makefile defines it to something different, then of course
your CXXFLAGS will be used as it is passed to all sub-`make' invocations
and all assignments in the upstream makefile(s) are ignored.

> authoritative documentation that explains that CXXFLAGS (and others)
> should be expected to be changed to local values by the user.

The Automake manual, or the GNU Coding Standards.  CFLAGS, CXXFLAGS,
CPPFLAGS, LDFLAGS, etc. are "user" variables so any build system that
does not respect the user's choice is kind of buggy.  At least for
packages using the GNU build system.  IOW, you should be able to define
all of these variables from within debian/rules and upstream's build
system should obey your choice.

See '(automake-1.10)Flag Variables Ordering'.

> My problem is that I do not know the contents of the implicit rule
> building the .o files from the .h files,

You can use `make -p' and examine make's internal database.

> nor how I can tell to make to
> add $(OTHERFLAGS) to this implicite rule.

You cannot if the built-in make rules are used, since make doesn't know
anything about that variable and it's not in the recipe.

But you can do ut with CPPFLAGS.  Something like this:

CPPFLAGS = -DVERSION="\"1.00\""
CXXFLAGS = -g -W -Wall -pedantic

proda : $(OBJECTS)
        $(CXX) $(CXXFLAGS) $(CPPFLAGS) -lm $(OBJECTS) -o proda

Even if you don't put $(CPPFLAGS) in the recipe, all the individual
objects will be built with -DVERSION=..., which is probably what you want.

Hope that helps.


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Plessy-12]

Le Wed, Jun 25, 2008 at 11:06:09AM +0000, Yavor Doganov a écrit :
>  
> > OTHERFLAGS = -DVERSION="\"1.00\""
> > CXXFLAGS = -g -W -Wall -pedantic $(OTHERFLAGS)
>
> Use CPPFLAGS for this -- of course the recipes should be properly written
> in order to have some effect.
 
> > authoritative documentation that explains that CXXFLAGS (and others)
> > should be expected to be changed to local values by the user.
>
> The Automake manual, or the GNU Coding Standards.  CFLAGS, CXXFLAGS,
> CPPFLAGS, LDFLAGS, etc. are "user" variables so any build system that
> does not respect the user's choice is kind of buggy.  At least for
> packages using the GNU build system.  IOW, you should be able to define
> all of these variables from within debian/rules and upstream's build
> system should obey your choice.

Thanks Yavor and everybody else for your answers.

I have added the following paragraph in http://wiki.debian.org/GettingPackaged 

  Some {{{make}}} variables are reserved to the user, and the
  [http://www.gnu.org/software/libtool/manual/automake/User-Variables.html#User-Variables
  Automake manual] and the
[http://www.gnu.org/prep/standards/standards.html#Command-Variables GNU coding
  standards] advise to never use them for switches that are required for proper
  compilation of the package. When a Debian binary package is built, variables
  such as {{{CFLAGS}}}, {{{CXXFLAGS}}}, {{{CPPFLAGS}}},... are set in the
  environnement and override the ones in the {{{Makefile}}}. We of course
  strongly recommend to follow the above advice.

For Proda, if I pass -DVERSION="\"1.00\"" through CPPFLAGS, it indeeds
solves my problem. But what can I propose upstream that fits the best
practices that I just added to the wiki? If CPPFLAGS is set in the
Makefile, it could be overriden, but if it is set to
-DVERSION="\"1.00\"" from debian/rules, then this is one more think that
one can forget to update when a new upstream version is released...

Have a nice day,

--
Charles


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Yavor Doganov-3]

В Wed, 25 Jun 2008 23:14:44 +0900, Charles Plessy написа:

>   When a Debian binary package is
>   built, variables such as {{{CFLAGS}}}, {{{CXXFLAGS}}},
>   {{{CPPFLAGS}}},... are set in the environnement and override the ones
>   in the {{{Makefile}}}.

That's not entirely true and not entirely false.  It's closer to being
false, though.  Environment variables do not override the ones explicitly
set in the makefile (or on the command line), unless you do `make -e'.

If CFLAGS is set in the environment (f.i. by dpkg-buildpackage), and
you don't do any special handling in debian/rules, and it is defined
explicitly in upstream's makefile, the latter will be in effect.

If upstream's makefile does not define the variable, but instead has
rules with commands including $(CFLAGS), the value set by
dpkg-buildpackage will be used.

If you define

CFLAGS = ...

in debian/rules, this is a make variable, not an environment variable,
and it won't propagate to sub-make.

However, if you do

$(MAKE) CFLAGS="$(CFLAGS)"

that value will be used for the build and will override upstream's value,
because variables defined on the command line override variables defined
in the makefile.

This is why it's very wrong to define CFLAGS directly in Makefile.am,
because the user cannot do

./configure CFLAGS=...

to override the value.  And the user is always right.

So the right thing to do depends on the package and/or the build system
in question.  As these things vary wildly and it seems new "inventions"
in this area is a vogue, I don't think that you can generalize and give a
common recipe that will work for all cases.

> For Proda, if I pass -DVERSION="\"1.00\"" through CPPFLAGS, it
> indeeds solves my problem.

Good.

> But what can I propose upstream that fits the best practices that I
> just added to the wiki?

I just downloaded 1.0-4 and the Makefile looks OK to me (apart from using
the variable for C++ compiler flags for preprocessor flags).  Of
course it's not portable, but that is another story.  With this define
in CPPFLAGS the behaviour is predictable and sane.

> If CPPFLAGS is set in the Makefile, it could be overriden, but if it
> is set to -DVERSION="\"1.00\"" from debian/rules, then this is one
> more think that one can forget to update when a new upstream version
> is released...

But this flag is upstream's and not a Debian modification, right?  If
so, you just have to modify your 02-fix_CXXFLAGS.patch until upstream
does the right thing in a new release.  Then you can just drop the
patch.

So If i were you I that patch would be only:

- OTHERFLAGS = -DVERSION="\"1.00\""
+ CPPFLAGS = -DVERSION="\"1.00\""

OTHERFLAGS will expand to the empty string, so it's harmless.


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Daniel Leidert]

Sorry for the CC. I was away and missed the discussion :)

Am Mittwoch, den 25.06.2008, 13:24 +0900 schrieb Charles Plessy:

> while working on an update to the `proda' package, I realised that a
> compilation option, DVERSION="\"1.00\"", was discarded during the build
> of the Debian binary package. The reason is very simple:
>
> OTHERFLAGS = -DVERSION="\"1.00\""
> CXXFLAGS = -g -W -Wall -pedantic $(OTHERFLAGS)

Talk to the upstream author to use e.g. (GNU make specific):

override CXXFLAGS += $(OTHERFLAGS)

or tell him to better use one of the following:

DEFS += -DVERSION="\"1.00\""
AM_CPPFLAGS += -DVERSION="\"1.00\""
foo_CPPFLAGS += -DVERSION="\"1.00\""
...

These are normnally not overwritten by the user and the correct place to
leave a -D switch. There is enough documentation out there to find the
correct solution.

[..]
> My problem is that I do not know the contents of the implicit rule
> building the .o files from the .h files, nor how I can tell to make to
> add $(OTHERFLAGS) to this implicite rule.
[..]
> Any idea ?

Read /usr/share/doc/make-doc/. There you find all built-in rules.

(Sorry, if you already got this information - I'm still
receiving/processing mails).

Regards, Daniel


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Yavor Doganov-3]

В Thu, 26 Jun 2008 23:14:55 +0200, Daniel Leidert написа:

> or tell him to better use one of the following:
>
> DEFS += -DVERSION="\"1.00\""

This won't work.  The objects are built by make's built-in implicit
rules, and this variable is not used there:

COMPILE.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c

Maybe it is OK for other make implementations (never used them, thank
goodness for that), but it will definitely have no effect with GNU make.

> AM_CPPFLAGS += -DVERSION="\"1.00\""
> foo_CPPFLAGS += -DVERSION="\"1.00\"" ...

These are Automake-specific and `proda' is not using Automake, not
even Autoconf.  It has one simple hand-written makefile.


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Daniel Leidert]

Am Freitag, den 27.06.2008, 10:16 +0000 schrieb Yavor Doganov:
> В Thu, 26 Jun 2008 23:14:55 +0200, Daniel Leidert написа:
>
> > or tell him to better use one of the following:
> >
> > DEFS += -DVERSION="\"1.00\""
>
> This won't work.  The objects are built by make's built-in implicit
> rules, and this variable is not used there:

Ok. I didn't recognize, that it doesn't use autotools.

> COMPILE.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
>
> Maybe it is OK for other make implementations

automake uses it. I think, then the override directive is the only
choice left from my suggestions. Unfortunately, freebsd-make will
probably not recognize it.

Regards, Daniel


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...