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

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

[Andrew Cagney]

Just FYI,

The proposal was for "make CFLAGS=..." be fixed so that it could control 
-Werror behavior at build time.  This is the important first step as it 
gives the developer fine-grained control over the build, for instance, 
being able to compile sinngle files without warnings vis:
    make GCJFLAGS='-g -O' frysk/bindir/fhpd.o
If that is working then controlling that at configure time with, say:
    .../configure GCJFLAGS='-g -O'
becomes possible.  Adding an option to also control this is just eye candy.

I'll commit changes to fix this.

Andrew

> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-common/Makefile.rules.diff?cvsroot=frysk&r1=1.195&r2=1.196
> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-common/frysk-common.ac.diff?cvsroot=frysk&r1=1.13&r2=1.14
> http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-common/m4/frysk_werror.m4.diff?cvsroot=frysk&r1=NONE&r2=1.1
>
>   

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

[Kris Van Hees]

As you are well aware, the requirement for this came from the need to be
able to run tests even in the event of warnings being triggered during
the build.  That requirement was expressed by myself on the IRC channel
yesterday, and led to a lengthy discussion about the impact of this
change, and was explained at great length.

You suggested first imeplementing this as something to control on the
make command line, and I responded quite clearly that I might implement
it as a configure option right away, especially since it was (before
your and my changes) controlled by a hardcoded AM_GCJFLAGS variable.
You pointed out that change was easy, and that you moved the wiring of
the -Werror flag to common/frysk-common.ac (from Makefile.rules).  I
requested you to let me know what that change was commited, which you
never did.

As I explained at great length yesterday on the IRC channel, controlling
this from the make command line is error prone, and is not a reasonable
solution for using this in automated builds, where dependency on the
exactness of the *FLAGS variables is a liability because changes in the
tree may require those variables to be tweaked, which is (for default
builds) handled nicely by theautoconf/automake/configure setup, but
would require manual intervention (once someone notices the problem -
which could take a while).  Allowing this to be controlled in a clean
and consistent way, maintained as part of the tree so it is known to be
consistent and correct will save quite a few headaches, and follows the
pattern set by numerous autoconf-based projects throughout the
community.  This is hardly an exception.

Again, we went over all this yesterday.  I am somewhat at a loss why
this has to get re-discussed yet again.  Surely we can use our time in a
more productive manner.

	Cheers,
	Kris

Mar 08 14:02:33 cagney  SqRoot, so can you work through the issues with
getting "make *FLAGS=" working as one would expect?  Control "-g -O -Werror"?
Hopefuly elena isn't going to spin that me asking for that is stonewalling


On Fri, Mar 09, 2007 at 10:54:51AM -0500, Andrew Cagney wrote:
> Just FYI,
> 
> The proposal was for "make CFLAGS=..." be fixed so that it could control 
> -Werror behavior at build time.  This is the important first step as it 
> gives the developer fine-grained control over the build, for instance, 
> being able to compile sinngle files without warnings vis:
>    make GCJFLAGS='-g -O' frysk/bindir/fhpd.o
> If that is working then controlling that at configure time with, say:
>    .../configure GCJFLAGS='-g -O'
> becomes possible.  Adding an option to also control this is just eye candy.
> 
> I'll commit changes to fix this.
> 
> Andrew
> 
> >http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-common/Makefile.rules.diff?cvsroot=frysk&r1=1.195&r2=1.196
> >http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-common/frysk-common.ac.diff?cvsroot=frysk&r1=1.13&r2=1.14
> >http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-common/m4/frysk_werror.m4.diff?cvsroot=frysk&r1=NONE&r2=1.1
> >
> >  
> 

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

[Kris Van Hees]

After more discussion on #frysk, the following was decided:

- configure should honour manual specifying of the CFLAGS, CXXFLAGS, and
  GCJFLAGS on the command line, i.e. configure should not alter any of
  those variables *regardless* of options specified to configure.
- as such, configure --disable-werror (and similarly, --enable-werror)
  will not affect ant of these variables that are specified on the command
  line
- similarly, the logic to change "-g -O2" into '-g -O" is not to be
  applied if the variable it occurs in was specified as a command line
  setting

In summary, when one or more of CFLAGS, CXXFLAGS, GCJFLAGS is specified
on the command line, configure will not honour implicit logic or options
that would modify such variable.

This bug fix to the --disable-werror logic checked in, and the long
existing logic to handle the listed variables is currently being worked
on.  I'll open a bugzilla, assigned to me, with this list message to
track the development.

	Cheers,
	Kris

On Fri, Mar 09, 2007 at 08:15:20AM -0800, Kris Van Hees wrote:
> As you are well aware, the requirement for this came from the need to be
> able to run tests even in the event of warnings being triggered during
> the build.  That requirement was expressed by myself on the IRC channel
> yesterday, and led to a lengthy discussion about the impact of this
> change, and was explained at great length.
> 
> You suggested first imeplementing this as something to control on the
> make command line, and I responded quite clearly that I might implement
> it as a configure option right away, especially since it was (before
> your and my changes) controlled by a hardcoded AM_GCJFLAGS variable.
> You pointed out that change was easy, and that you moved the wiring of
> the -Werror flag to common/frysk-common.ac (from Makefile.rules).  I
> requested you to let me know what that change was commited, which you
> never did.
> 
> As I explained at great length yesterday on the IRC channel, controlling
> this from the make command line is error prone, and is not a reasonable
> solution for using this in automated builds, where dependency on the
> exactness of the *FLAGS variables is a liability because changes in the
> tree may require those variables to be tweaked, which is (for default
> builds) handled nicely by theautoconf/automake/configure setup, but
> would require manual intervention (once someone notices the problem -
> which could take a while).  Allowing this to be controlled in a clean
> and consistent way, maintained as part of the tree so it is known to be
> consistent and correct will save quite a few headaches, and follows the
> pattern set by numerous autoconf-based projects throughout the
> community.  This is hardly an exception.
> 
> Again, we went over all this yesterday.  I am somewhat at a loss why
> this has to get re-discussed yet again.  Surely we can use our time in a
> more productive manner.
> 
> 	Cheers,
> 	Kris
> 
> Mar 08 14:02:33 cagney  SqRoot, so can you work through the issues with
> getting "make *FLAGS=" working as one would expect?  Control "-g -O -Werror"?
> Hopefuly elena isn't going to spin that me asking for that is stonewalling
> 
> 
> On Fri, Mar 09, 2007 at 10:54:51AM -0500, Andrew Cagney wrote:
> > Just FYI,
> > 
> > The proposal was for "make CFLAGS=..." be fixed so that it could control 
> > -Werror behavior at build time.  This is the important first step as it 
> > gives the developer fine-grained control over the build, for instance, 
> > being able to compile sinngle files without warnings vis:
> >    make GCJFLAGS='-g -O' frysk/bindir/fhpd.o
> > If that is working then controlling that at configure time with, say:
> >    .../configure GCJFLAGS='-g -O'
> > becomes possible.  Adding an option to also control this is just eye candy.
> > 
> > I'll commit changes to fix this.
> > 
> > Andrew
> > 
> > >http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-common/Makefile.rules.diff?cvsroot=frysk&r1=1.195&r2=1.196
> > >http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-common/frysk-common.ac.diff?cvsroot=frysk&r1=1.13&r2=1.14
> > >http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-common/m4/frysk_werror.m4.diff?cvsroot=frysk&r1=NONE&r2=1.1
> > >
> > >  
> > 

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

[Mark Wielaard]

Hi Kris,

On Fri, 2007-03-09 at 10:03 -0800, Kris Van Hees wrote:
> In summary, when one or more of CFLAGS, CXXFLAGS, GCJFLAGS is specified
> on the command line, configure will not honour implicit logic or options
> that would modify such variable.
> 
> This bug fix to the --disable-werror logic checked in, and the long
> existing logic to handle the listed variables is currently being worked
> on.  I'll open a bugzilla, assigned to me, with this list message to
> track the development.

Could you explain what the correct way to handle these FLAGS would be
now? I see this is completely the opposite to how the configure logic
has been implemented in the past. common/frysk-common.ac explicitly
checks and resets the above flags and I found your configure changes
nicely follows that logic. How do you intend to make the above logic
work now? The problem seems to be that our build explicitly adds to
these flags (and strips things like -O2 from them) and at the same time
we want the user to override these same flags by adding or subtracting
different sets of flags. Although I see why you might want the above
setup it also looks like major surgery to the build scripts for little
gain. So please don't spend days on it. The build machinery is too
complicated as it is already. And if the only reason for the above
change is to make a build with different flags possible without a simple
reconfigure then I don't think it is really worth the effort (but I am
not the one doing the work, so please don't let me stop you if you love
build hacking!)

Cheers,

Mark

P.S. Be careful with adopting the build files they have some usage of
internal automake variables, like the *COMPILE ones. And I found it
pretty hard to adapt the build to have those work across automake
versions. Build file hacking can de addictive and eat up lots of time :)

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

[Andrew Cagney]

FYI,

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.

Andrew

Mark Wielaard wrote:
> Hi Kris,
>
> On Fri, 2007-03-09 at 10:03 -0800, Kris Van Hees wrote:
>   
>> In summary, when one or more of CFLAGS, CXXFLAGS, GCJFLAGS is specified
>> on the command line, configure will not honour implicit logic or options
>> that would modify such variable.
>>
>> This bug fix to the --disable-werror logic checked in, and the long
>> existing logic to handle the listed variables is currently being worked
>> on.  I'll open a bugzilla, assigned to me, with this list message to
>> track the development.
>>     
>
> Could you explain what the correct way to handle these FLAGS would be
> now? I see this is completely the opposite to how the configure logic
> has been implemented in the past. common/frysk-common.ac explicitly
> checks and resets the above flags and I found your configure changes
> nicely follows that logic. How do you intend to make the above logic
> work now? The problem seems to be that our build explicitly adds to
> these flags (and strips things like -O2 from them) and at the same time
> we want the user to override these same flags by adding or subtracting
> different sets of flags. Although I see why you might want the above
> setup it also looks like major surgery to the build scripts for little
> gain. So please don't spend days on it. The build machinery is too
> complicated as it is already. And if the only reason for the above
> change is to make a build with different flags possible without a simple
> reconfigure then I don't think it is really worth the effort (but I am
> not the one doing the work, so please don't let me stop you if you love
> build hacking!)
>
> Cheers,
>
> Mark
>
> P.S. Be careful with adopting the build files they have some usage of
> internal automake variables, like the *COMPILE ones. And I found it
> pretty hard to adapt the build to have those work across automake
> versions. Build file hacking can de addictive and eat up lots of time :)
>
>   

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

[Mark Wielaard]

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

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

[Andrew Cagney]

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
>
>