automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: automake's Per-Object Flags Emulation --- CFLAGS override or just pr


From: Stefano Lattarini
Subject: Re: automake's Per-Object Flags Emulation --- CFLAGS override or just prepend ?
Date: Sat, 09 Mar 2013 18:53:27 +0100

On 03/09/2013 06:26 PM, Michele Martone wrote:
> On address@hidden:58, Stefano Lattarini wrote:
>> On 03/09/2013 04:43 PM, Michele Martone wrote:
>>> Hi,
>>>
>>> I'm using the "Per-Object Flags Emulation" functionality of automake
>>> to build a single library (.a) file from two .a files, each made of .o
>>> files compiled with different flags.
>>>
>>> In order to apply the example of
>>>  
>>> http://www.gnu.org/software/automake/manual/automake.html#Per_002dObject-Flags
>>>  
>>> in my Makefile.am, I declare something similar to
>>>   libfoo_a_CFLAGS = -some -other -flags
>>> expecting that libfoo.a will be compiled with -some -other -flags 
>>> rather than CFLAGS.
>>>
>>> However in the resulting Makefile I see that something like the
>>> following:
>>>  libfoo_a-foo.o: foo.c
>>>          $(CC) ... $(libfoo_a_CFLAGS) $(CFLAGS) ...
>>> is being generated instead.
>>> In other words, CFLAGS is not being replaced by libfoo_a_CFLAGS: only
>>> prepended:
>>>
>> This is correct: CFLAGS is a user-reserved variable, so it should always
>> be honoured and should never be overridden by Automake rules (nor by
>> package developers).  The correct developer-reserved variable to specify
>> extra C compilation flags is AM_CFLAGS -- and *that* is being correctly
>> overwritten.
> 
> Thanks Stefano -- makes sense to me, although this was not clear from the
> manual.
> (maybe it needs a correction ? I would suggest using 
>  "will be compiled using also" instead of "will be compiled using").
>
No, the "also" would suggest that '-some -flags' are used too, while in fact,
only '-some -other -flags' are.   Still, to reduce the chance for confusion,
we could explicitly state that $(CFLAGS) is still used in both cases; while
that is already implied by other parts of the documentation, this might be
one of the cases where "repetita juvant".  Patches welcome.

> But, is there a clean way for preventing CFLAGS being used for some
> library files ?
>
Not that I know of; and it's by design: doing that would prevent user
customization, which is a Bad Thing.

> In a way to get in Makefile rules like:
>  libfoo_a-foo.o: foo.c
>          $(CC) ... $(libfoo_a_CFLAGS)  ...
> instead of:
>  libfoo_a-foo.o: foo.c
>          $(CC) ... $(libfoo_a_CFLAGS) $(CFLAGS) ...
> 
> or at least to get a custom "AM_POST_CFLAGS" appended *after* CFLAGS:
>  libfoo_a-foo.o: foo.c
>          $(CC) ... $(libfoo_a_CFLAGS) $(CFLAGS) $(AM_POST_CFLAGS) ...
> 
> ?
> 
> In such a way, I (developer) may use AM_POST_CFLAGS to introduce some 
> flags that may invalidate some undesired CFLAGS (e.g.: invalidate 
> loop unrolling flags that may be implied by CFLAGS).
>
I'd say, don't do that either; just state in your README or INSTALL file
(or similar documentation) that such flags are unsupported or discouraged.
If a user wants to shoot himself in the foot by ignoring your advice, let
him.  This is UNIX :-)

HTH,
  Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]