This is the mail archive of the frysk@sources.redhat.com mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]