Re: Difference between AM_CFLAGS, AM_CPPFLAGS, and AM_LDFLAGS
On Tue, 2002-09-10 at 01:06, Paul Smith wrote: Steve gave you the advantage: so you can run them individually. There are many compilers that won't accept linker flags (libraries, etc.) on a command line meant to compile a file (but not link it). The reason for having a separate CFLAGS and CPPFLAGS is even stronger: often you want to just run the C preprocessor (or a tool that takes the same arguments as the C preprocessor) either for debugging, or running tools like lint, or instrumenting your code with special debugging capabilities, etc. In this case you need to be able to run the preprocessor and be sure you're getting all the same arguments as when you compile the code into an object file. Thanks for the reply. I will work on the project separating the the flags into the three variables. Stephen
Re: Automake 1.6.3 issue
Akim Demaille wrote:
| Cool. Since we do not need amk 1.6.3 for our build,
| I will change the configure.ac requirement to 1.6.2,
| which does work.
What ... ??? The bug I'm referring to is only the
fact that the error message did not say `1.6.3 is a version of
Automake'. There is no known bug in 1.6.3, and if 1.6.2 did not
complain, then it was a bug in 1.6.2.
We are talking about several errors:
1. autoconf macro for automake version check did not say the
version mismatch was due to an automake version.
Alexandre is fixing that. Thanks.
2. The automake error reporting bug that said I did something bad,
but there was not enough information to find the problem
/usr/local/share/automake-1.6/am/header-vars.am: \
pkgincludedir was already defined in condition TRUE, \
which implies condition INSTALL_SNPRINTFV_TRUE
pkgincludedir (Automake, where = \
/usr/local/share/automake-1.6/am/header-vars.am) =
{
TRUE = $(includedir)/PACKAGE
}
error: bootstrap failed
I'm sure this makes sense to someone in the bowels of automake,
but I'm afraid not to me.
3. The change in behavior between automake 1.6.2 and 1.6.3.
My project builds without a single warning on 1.6.2, therefore
the failure to configure, let alone build, is a bug in 1.6.3.
It should to be made a warning before an error; minimally
the real problem cause must be reported (see #2 above).
4. The indeterminable misuse in one of my Makefile.am's:
Makefile.am
config/Makefile.am
autoopts/Makefile.am
autoopts/test/Makefile.am
agen5/Makefile.am
agen5/test/Makefile.am
doc/Makefile.am
columns/Makefile.am
getdefs/Makefile.am
getdefs/test/Makefile.am
xml2ag/Makefile.am
snprintfv/Makefile.am
snprintfv/tests/Makefile.am
snprintfv/snprintfv/Makefile.am
snprintfv/doc/Makefile.am
snprintfv/config/Makefile.am
There may be more, but our network is dying, so I did it from memory.
I confess, I'm not jumping at the opportunity to debug these.
They've been working successfully ever since I accommodated
Automake's change in behavior on distcheck. At least that one
had a traceable symptom. I was not asking or expecting you to
jump at it either. I just consider 1.6.3 broken and want it out
of the build dependency.
Re: Automake 1.6.3 issue
Hi Bruce! Bruce == Bruce Korb [EMAIL PROTECTED] writes: [...] Bruce 2. The automake error reporting bug that said I did something bad, Bruce but there was not enough information to find the problem /usr/local/share/automake-1.6/am/header-vars.am: \ pkgincludedir was already defined in condition TRUE, \ which implies condition INSTALL_SNPRINTFV_TRUE [...] Bruce I'm sure this makes sense to someone in the bowels of automake, Bruce but I'm afraid not to me. `pkgincludedir' is a standard Automake variable defined to `$(includedir)/@PACKAGE@' always (= condition TRUE). You are alowed to overwrite the variable if you want, but only in the condition where it was initially defined. I.e., you can do pkgincludedir = something but you can't do if INSTALL_SNPRINTFV pkgincludedir = something endif If you need something like the latter (given the name of the conditional I doubt it), you can use your own dir-variable: if INSTALL_SNPRINTFV mypkgincludedir = something else mypkgincludedir = $(pkgincludedir) endif mypkginclude_LIBRARIES=... Bruce 3. The change in behavior between automake 1.6.2 and 1.6.3. Bruce My project builds without a single warning on 1.6.2, therefore Bruce the failure to configure, let alone build, is a bug in 1.6.3. It's a bug in Automake 1.6.2 and earlier that this was allowed, sorry. The Makefile produced by 1.6.2 from this erroneously-allowed construction is bogus. See http://sources.redhat.com/ml/automake/2002-06/msg00143.html Bruce 4. The indeterminable misuse in one of my Makefile.am's: The error location should be improved, this is PR/353. However, I presume not all your Makefiles use both INSTALL_SNPRINTFV and pkgincludedir, so it shouldn't be that hard to locate. [...] -- Alexandre Duret-Lutz
Re: Automake 1.6.3 issue
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes: [...] adl However, I presume not all your Makefiles use both adl INSTALL_SNPRINTFV and pkgincludedir, so it shouldn't be that adl hard to locate. You can also try `automake --verbose', this will print any file read, so you can see what was the last Makefile.am opened. -- Alexandre Duret-Lutz
Re: Automake 1.6.3 issue
Alexandre wrote:
/usr/local/share/automake-1.6/am/header-vars.am: \
pkgincludedir was already defined in condition TRUE, \
which implies condition INSTALL_SNPRINTFV_TRUE
You are alowed to overwrite the variable if you want, but only
in the condition where it was initially defined. I.e.,
you can do
pkgincludedir = something
but you can't do
if INSTALL_SNPRINTFV
pkgincludedir = something
endif
Thanks, Alexandre. I ought to be able to find the issue.
This probably narrows it to one potential .am file, too.
It's a bug in Automake 1.6.2 and earlier that this was allowed,
sorry. The Makefile produced by 1.6.2 from this
erroneously-allowed construction is bogus. See
http://sources.redhat.com/ml/automake/2002-06/msg00143.html
Another approach is to go ahead and emit the Makefile.in,
but also emit a warning like this:
cat 2 _EOF_
* * * * * * * * * * * * * * * * * * * * * * * * * * * * *
WARNING: you seem to be misusing ${variable} in ${filename}
${variable} is always used by automake, but it appears in
conditional text. This is almost certainly a mistake.
See: http://sources.redhat.com/ml/automake/2002-06/msg00143.html
And see: http://www.gnu.org/software/automake/unconditional-use.html
for more information.
MEANWHILE: we are creating the output file so you won't be
dead in the water, but you should fix your ${filename} file
and be aware there may be unexpected results.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * *
_EOF_
sleep 30
Re: Automake 1.6.3 issue
On Tue, Sep 10, 2002 at 10:59:15AM -0700, Bruce Korb wrote:
Another approach is to go ahead and emit the Makefile.in,
but also emit a warning like this:
cat 2 _EOF_
* * * * * * * * * * * * * * * * * * * * * * * * * * * * *
WARNING: you seem to be misusing ${variable} in ${filename}
${variable} is always used by automake, but it appears in
conditional text. This is almost certainly a mistake.
See: http://sources.redhat.com/ml/automake/2002-06/msg00143.html
And see: http://www.gnu.org/software/automake/unconditional-use.html
for more information.
MEANWHILE: we are creating the output file so you won't be
dead in the water, but you should fix your ${filename} file
and be aware there may be unexpected results.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * *
_EOF_
G!
A simple warning message, please:
${filename}: WARNING: ${variable} appears in conditional text
The rest belongs in the manual, *not* on stderr.
sleep 30
*Shudder*
--
| | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
[...] despite reports to the contrary, it is the rare programmer who
permanently loses his sanity while coding (permanently being the
operative word).
- Eric E. Allen
Re: Automake 1.6.3 issue
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes: adl You are alowed to overwrite the variable if you want, but only in adl the condition where it was initially defined. I.e., you can do adl pkgincludedir = something adl but you can't do adl if INSTALL_SNPRINTFV adl pkgincludedir = something adl endif I've long thought that we should, eventually, support the latter use. It seems to have a clearly defined meaning. And it is even useful in some situations. For instance, suppose in a very large project you want to `include' some boilerplate. Then you might conditionally override some value or another in a particular Makefile.am. Before Akim's rewrite of variable handling, we really couldn't do this. We just didn't have the internal abstractions. Now it might be possible, but I haven't looked. Tom
