automake
[Top][All Lists]
Advanced

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

Re: XXX_CFLAGS


From: Alexandre Duret-Lutz
Subject: Re: XXX_CFLAGS
Date: 13 Aug 2001 21:06:09 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>> "Ralf" == Ralf Corsepius <address@hidden> writes:

[...]

 Ralf> * I would expect <program|library>_CFLAGS to be handled similiar to
 Ralf> INCLUDES or DEFS (except for not being applied globally), but I do not
 Ralf> expect it to rename files.

BTW, another difference is that per-target CFLAGS also imply
per-object compilation rules which can result in a significant
grow of the Makefile size on large projects.

 Ralf> * Similarily, I would expect hello_c_o_CFLAGS to be applied to the
 Ralf> compilation of a single *.c/o's only.

 Ralf> * I don't see why using a single set of per-target CFLAGS
 Ralf> causes the necessity of rename the files.  Renaming them
 Ralf> when using several such FLAGS for a _single_ target to
 Ralf> compile files multiple times might give sence. AFAIU,
 Ralf> multiple compilation however still requires to code the
 Ralf> flags into Makefile.am, therefore it should be detectable
 Ralf> by automake and therefore it should be technically
 Ralf> possible to keep the old naming until multiple compiles
 Ralf> are used.

This sounds sensible to me (actually I wished that too the first
time I tried per-target CFLAGS).

Besides, if Automake was taught how to compute conflicting
object filenames (to rename only those files).  It could also be
improved to accept `a.c' and `a.cpp' in the same program (I
believe it doesn't support this, does it?).

[...]

 Ralf> I am not sure, but I suspect the naming not being safe against DOS/Win
 Ralf> filenaming conventions (At the moment, I don't have access to such
 Ralf> systems, so can't validate this statement).

I think you could use `hello_c_SHORTNAME = h'.
-- 
Alexandre Duret-Lutz




reply via email to

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