Re: frysk-common ./ChangeLog ./Makefile.rules ./fr ...

[Andrew Cagney <cagney at redhat dot com>]

Mark,

Yes, Kris's changes better align things to automake's recommendations:

CC:
This should be set using configure when the base compiler's behavior 
needs to be changed.  For instance, when doing a 64-bit build on the PPC 
where the default is to compile 32-bit, the 64-bit compiler must be 
explicitly specified vis:
    $ configure CC='gcc -m64'

CFLAGS:
These are the compiler options a user expects to be able to adjust as 
part of a compile.  For instance, the presence of debug information, or 
the optimization level.  Again a user can adjust them during configure, 
or during make vis:
   $ configure CFLAGS='-g -O0'
   $ make CFLAGS='-g -O0'
Automake is understandably hostile towards CFLAGS being set in .am files 
- controlling CFLAGS is autoconf's and not automake's domain.

AM_CFLAGS:
Finally, as you note, there are the automake flags required for the 
build.  In particular include flags or defines determined as part of the 
config process, or required as part of the build.  Since they would not 
normally be adjusted they are not put in CFLAGS, if they were, instead of:
   $ make CFLAGS='-g -O0'
a convoluted like such as:
   $ make CFLAGS='-g -O0 -I../frysk-imports/include 
-I../../frysk/frysk-imports/include -I....'
would need to be specified.

If -Werror is something the user may want to adjust then it belongs in 
CFLAGS and should be handled outside of automake by autoconf.

There's nothing radical here, just bug fixes for what were simplistic hacks.

Andrew

Mark Wielaard wrote:
> Hi Andrew,
>
> On Mon, 2007-03-12 at 11:02 -0400, Andrew Cagney wrote:
>   
> > The current configury which unconditionally adds in, or edits CFLAGS 
> > et.al., is wrong.  Instead when CFLAGS, say, is specified on the 
> > configure line then its values should be 100% followed.  The add/edit 
> > only occuring when no CFLAGS was specified.
> >     
>
> Yes, that is what Kris also said. But what is the plan to redesign our
> build to make that work? And why was it designed to be that way in the
> first place?
>
> Normally I would follow the automake recommendations
> http://sources.redhat.com/automake/automake.html#Flag-Variables-Ordering
> But our current build system seems a little hostile towards that. That
> setup assumes that you only manipulate AM flags and per-target flags in
> your configure and build rules and that the user variables override that
> behavior (by tagging CFLAGS on the end, which assumes that flags given
> later to a tool cancel out earlier flags). But in the current build we
> seem to want to explicitly mangle the given user flags, so I am
> wondering why we do that. And currently we seem to depend on a couple of
> internal automake variables which make things even more messy. So unless
> someone has a good plan of cleaning this all up I would not bother with
> it if things work now. Not saying the current build system is good, or
> that I wouldn't be overjoyed with a cleaned up one. Just curious how to
> get there.
>
> Cheers,
>
> Mark
>
>