[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