Re: automake/44: conditional redefinitions (Was: Re: Automake 1.6.3 issue)
| This also works for things like | | foo = mumble | foo = blurgle | | which would be interpreted as | | foo = blurgle | if FALSE | foo = mumble | endif I've always thought this is wrong. I still think we should not support such ``feature'', which is a form of laxism to me, comparable to globbing. Nevertheless, I agree a means to install defaults would be most welcome. I suggest introducing foo ?= bar Which is always valid, but with a clear semantics. Also, maybe we want to introduce something like (hold you breath): ifndef foo foo = bar endif
Re: back quotes and double quotes must not be escaped?
| Since upgrading from autoconf 2.54 to 2.54b, automake 1.7.1 gives me tons | of warnings: | | configure.ac:27: warning: back quotes and double quotes must not be escaped in: |$as_me:$LINENO: WARNING: \`$CC' requires \`$lt_cv_prog_cc_shlib' to build shared |libraries | configure.ac:27: warning: back quotes and double quotes must not be escaped in: |$as_me: WARNING: \`$CC' requires \`$lt_cv_prog_cc_shlib' to build shared libraries | configure.ac:27: warning: back quotes and double quotes must not be escaped in: |$as_me:$LINENO: WARNING: add \`$lt_cv_prog_cc_shlib' to the CC or CFLAGS env variable |and reconfigure | | This is configure.ac line 27: | | AC_PROG_LIBTOOL | | What's the problem? libtool is version 1.4.3. This is not automake, but autoconf speaking. 2.55 will re-disable this warning until Libtool has this fixed :( Sorry.
Autoconf 2.54c is relased
The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
to annonce the second beta of forthcoming Autoconf 2.55. Download,
compile, install, torture, and enjoy!
- Why should I upgrade from 2.54?
A few bug fixes, improved portability, no known incompatibility with
2.54 and 2.55, forthcoming Gettext release might require 2.55.
Running `autoreconf -fv' should be enough.
- Why should I upgrade from 2.13?
This version is no longer maintained. It does not address recent
architectures, recent compilers etc. We know that upgrading from 2.13
to 2.5x is not an easy task, especially because the Autoconf 2.13 was
extremely tolerant to incorrect macro invocations, but waiting longer
endangers the portability of your package and only delays the
conversation to newer Autoconf versions. Worse: some maintainers now
spend a significant amount of time fixing bugs in 2.13 or backporting
macros from 2.55.
- Where can I find it?
ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54c.tar.gz (1.1 MB)
ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54c.tar.bz2 (792 KB)
And here are xdelta-style diffs
ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54b-2.54c.xdelta (17 KB)
Here are the MD5 and SHA1 signatures:
ab431fb26babf82de8fda486afb94350 autoconf-2.54c.tar.gz
db32dbbcd1bf2f8ca7713faa58bc905e autoconf-2.54c.tar.bz2
39bdbfc39b0581bda303e3b42a550714 autoconf-2.54b-2.54c.xdelta
807d67c59445ddac573dd8c9a42ac668b83020f0 autoconf-2.54c.tar.gz
9968922141aaf313ed145fe19d27669fd5f89189 autoconf-2.54c.tar.bz2
dd01917057f9f456e96259734ebc56a2b22f11ef autoconf-2.54b-2.54c.xdelta
NEWS:
Release tips:
Have your configure.ac checked by autoscan ("autoscan").
Try the warning options ("autoreconf -fv -Wall").
** Documentation
- AC_CHECK_HEADER, AC_CHECK_HEADERS
More information on proper use.
- Writing Test Programs
This sections explains how to write good test sources to use with
AC_COMPILE_IFELSE etc. It documents AC_LANG_PROGRAMS and so forth.
- AC_FOO_IFELSE vs. AC_TRY_FOO
Explains why Autoconf moves from AC_TRY_COMPILE etc. to
AC_COMPILE_IFELSE and AC_LANG_PROGRAM etc.
** autoreconf
- Is more robust to different Gettext installations.
- Produces messages (when --verbose) to be understood by Emacs'
compile mode.
- Supports -W/--warnings.
- -m/--make
Once the GNU Build System reinstalled, run `./config.status
--recheck && ./config.status && make' if possible.
** autom4te
- Supports --cache, and --no-cache.
- ~/.autom4te.cfg makes it possible to disable the caching mechanism
(autom4te.cache). See `Customizing autom4te' in the documentation.
** Obsolete options
Support for the obsoleted options -m, --macrodir, -l, --localdir is
dropped in favor of the safer --include/--prepend-include scheme.
** Macros
- New macros
AC_COMPILER_IFELSE, AC_FUNC_MBRTOWC, AC_HEADER_STDBOOL,
AC_LANG_CONFTEST, AC_LANG_SOURCE, AC_LANG_PROGRAM, AC_LANG_CALL,
AC_LANG_FUNC_TRY_LINK, AC_MSG_FAILURE, AC_PREPROC_IFELSE.
- Obsoleted
Obsoleted macros are kept for Autoconf backward compatibility, but
should be avoided in configure.ac. Running autoupdate is advised.
AC_DECL_SYS_SIGLIST.
** Bug Fixes
- Portability of the Autoconf package to Solaris.
- Spurious warnings caused by config.status.
This bug is benign, but painful: on some systems (typically
FreeBSD), warnings such as:
config.status: creating Makefile
mv: Makefile: set owner/group (was: 1357/0): Operation not permitted
could be issued. This is fixed.
- Parallel Builds
Simultaneous executions of config.status are possible again.
- Precious variables accumulation
config.status could stack several copies of the precious variables
assignments.
** Plans for 2.56
- ./configure
The compatibility hooks with the old scheme will be completely
removed. Please, advice/use `--build', `--host', and `--target'
only.
- AC_CHECK_HEADER, AC_CHECK_HEADERS
The tests will be stricter, please make sure your invocations are
valid.
- shell functions
Shell functions will gradually be introduced, probably starting with
Autotest. If you know machines which are in use that you suspect
*not* to support shell functions, please run the test suite of
Autoconf 2.55 on it, and report the results to
[EMAIL PROTECTED]
ChangeLog entries:
**
ChangeLog 4 Nov 2002 08:47:39 - 1.2092
**
2002-11-04 Akim Demaille <[EMAIL PROTECTED]>
Version 2.54c.
* Makefile.maint (update, cvs-update, po-update, do-po-update):
New.
* config/texinfo.tex: Update.
2002-11-03 Akim Demaille <[EMAIL PROTECTED]>
* bin/autoreconf.in (&autoreconf_current_directory): New, extracted
from...
Re: weird flags set by configure
> "Bob" == Bob Proulx <[EMAIL PROTECTED]> writes: Bob> If you want to change this you can set CXXFLAGS at configure Bob> time. Bob> CFLAGS=-O CXXFLAGS=-O ./configure ./configure CFLAGS=-O CXXFLAGS=-O is better.
Autoconf 2.55 is released!
The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
to annonce the birth of Autoconf 2.55. Download, compile, install,
torture, and enjoy!
- Why should I upgrade from 2.54?
A few bug fixes, improved portability, no known incompatibility with
2.54 and 2.55, forthcoming Gettext release might require 2.55.
Running `autoreconf -fv' should be enough.
- Why should I upgrade from 2.13?
This version is no longer maintained. It does not address recent
architectures, recent compilers etc. We know that upgrading from 2.13
to 2.5x is not an easy task, especially because the Autoconf 2.13 was
extremely tolerant to incorrect macro invocations, but waiting longer
endangers the portability of your package and only delays the
conversation to newer Autoconf versions. Worse: some maintainers now
spend a significant amount of time fixing bugs in 2.13 or backporting
macros from 2.55.
- Where can I find it?
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.55.tar.gz (1.1 MB)
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.55.tar.bz2(794 KB)
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.54-2.55.delta (70 KB)
and soon from the mirrors listed on http://www.gnu.org/order/ftp.html.
Here are the MD5 and SHA1 signatures:
d3e8ad97aa69853778125177967ed573 autoconf-2.55.tar.gz
4517bb0669b949935967f31329a29c0c autoconf-2.55.tar.bz2
c991edb76acbf686bed4ce1cb7a35cc2 autoconf-2.54-2.55.xdelta
69554487aec8606a17c53db2c7c7964be7138946 autoconf-2.55.tar.gz
d6d7cf9a2df8736c2930d1e6104de9c7a8ccbaff autoconf-2.55.tar.bz2
717df2957e85ad4de9c3c651a5b3eff1b01e3857 autoconf-2.54-2.55.xdelta
NEWS:
Release tips:
Have your configure.ac checked by autoscan ("autoscan").
Try the warning options ("autoreconf -fv -Wall").
** Documentation
- AC_CHECK_HEADER, AC_CHECK_HEADERS
More information on proper use.
- Writing Test Programs
This sections explains how to write good test sources to use with
AC_COMPILE_IFELSE etc. It documents AC_LANG_PROGRAMS and so forth.
- AC_FOO_IFELSE vs. AC_TRY_FOO
Explains why Autoconf moves from AC_TRY_COMPILE etc. to
AC_COMPILE_IFELSE and AC_LANG_PROGRAM etc.
** autoreconf
- Is more robust to different Gettext installations.
- Produces messages (when --verbose) to be understood by Emacs'
compile mode.
- Supports -W/--warnings.
- -m/--make
Once the GNU Build System reinstalled, run `./config.status
--recheck && ./config.status && make' if possible.
** autom4te
- Supports --cache, and --no-cache.
- ~/.autom4te.cfg makes it possible to disable the caching mechanism
(autom4te.cache). See `Customizing autom4te' in the documentation.
** Obsolete options
Support for the obsoleted options -m, --macrodir, -l, --localdir is
dropped in favor of the safer --include/--prepend-include scheme.
** Macros
- New macros
AC_COMPILER_IFELSE, AC_FUNC_MBRTOWC, AC_HEADER_STDBOOL,
AC_LANG_CONFTEST, AC_LANG_SOURCE, AC_LANG_PROGRAM, AC_LANG_CALL,
AC_LANG_FUNC_TRY_LINK, AC_MSG_FAILURE, AC_PREPROC_IFELSE.
- Obsoleted
Obsoleted macros are kept for Autoconf backward compatibility, but
should be avoided in configure.ac. Running autoupdate is advised.
AC_DECL_SYS_SIGLIST.
** Bug Fixes
- Portability of the Autoconf package to Solaris.
- Spurious warnings caused by config.status.
This bug is benign, but painful: on some systems (typically
FreeBSD), warnings such as:
config.status: creating Makefile
mv: Makefile: set owner/group (was: 1357/0): Operation not permitted
could be issued. This is fixed.
- Parallel Builds
Simultaneous executions of config.status are possible again.
- Precious variables accumulation
config.status could stack several copies of the precious variables
assignments.
** Plans for 2.56
- ./configure
The compatibility hooks with the old scheme will be completely
removed. Please, advice/use `--build', `--host', and `--target'
only.
- AC_CHECK_HEADER, AC_CHECK_HEADERS
The tests will be stricter, please make sure your invocations are
valid.
- shell functions
Shell functions will gradually be introduced, probably starting with
Autotest. If you know machines which are in use that you suspect
*not* to support shell functions, please run the test suite of
Autoconf 2.55 on it, and report the results to
[EMAIL PROTECTED]
Autoconf 2.56 is released
The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
to annonce the birth of Autoconf 2.56, aka 2.55 with a packaging
problem fixed.
- Why should I upgrade from 2.54?
A few bug fixes, improved portability, no known incompatibility with
2.54 and 2.55, forthcoming Gettext release might require 2.55. See
below for the list of user visible changes.
Running `autoreconf -fv' should be enough.
- Why should I upgrade from 2.13?
This version is no longer maintained. It does not address recent
architectures, recent compilers etc. We know that upgrading from 2.13
to 2.5x is not an easy task, especially because the Autoconf 2.13 was
extremely tolerant to incorrect macro invocations, but waiting longer
endangers the portability of your package and only delays the
conversation to newer Autoconf versions. Worse: some maintainers now
spend a significant amount of time fixing bugs in 2.13 or backporting
macros from 2.55.
- Where can I find it?
ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.56.tar.gz (1.1 MB)
ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.56.tar.bz2 (795 KB)
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.54-2.56.delta (7 KB)
and soon from the mirrors listed on http://www.gnu.org/order/ftp.html.
Here are the MD5 and SHA1 signatures:
0e142e9bc890786845950e84ffb52adf autoconf-2.56.tar.gz
1b0ecb66f03af3f745981c7d8bfc2a91 autoconf-2.56.tar.bz2
edcb98aa66f5c74a579109aef9cf3270 autoconf-2.55-2.56.xdelta
afff4a43d0b71a05de7b72e5a493a3e94219160c autoconf-2.56.tar.gz
5d2b082c2c76476a28a3b7bc0b537ccf6b5ad6f6 autoconf-2.56.tar.bz2
e1befdcb8d1032964021e29d6ad17975a766aa13 autoconf-2.55-2.56.xdelta
NEWS:
Release tips:
Have your configure.ac checked by autoscan ("autoscan").
Try the warning options ("autoreconf -fv -Wall").
** Documentation
- AC_CHECK_HEADER, AC_CHECK_HEADERS
More information on proper use.
- Writing Test Programs
This sections explains how to write good test sources to use with
AC_COMPILE_IFELSE etc. It documents AC_LANG_PROGRAMS and so forth.
- AC_FOO_IFELSE vs. AC_TRY_FOO
Explains why Autoconf moves from AC_TRY_COMPILE etc. to
AC_COMPILE_IFELSE and AC_LANG_PROGRAM etc.
** autoreconf
- Is more robust to different Gettext installations.
- Produces messages (when --verbose) to be understood by Emacs'
compile mode.
- Supports -W/--warnings.
- -m/--make
Once the GNU Build System reinstalled, run `./config.status
--recheck && ./config.status && make' if possible.
** autom4te
- Supports --cache, and --no-cache.
- ~/.autom4te.cfg makes it possible to disable the caching mechanism
(autom4te.cache). See `Customizing autom4te' in the documentation.
** Obsolete options
Support for the obsoleted options -m, --macrodir, -l, --localdir is
dropped in favor of the safer --include/--prepend-include scheme.
** Macros
- New macros
AC_COMPILER_IFELSE, AC_FUNC_MBRTOWC, AC_HEADER_STDBOOL,
AC_LANG_CONFTEST, AC_LANG_SOURCE, AC_LANG_PROGRAM, AC_LANG_CALL,
AC_LANG_FUNC_TRY_LINK, AC_MSG_FAILURE, AC_PREPROC_IFELSE.
- Obsoleted
Obsoleted macros are kept for Autoconf backward compatibility, but
should be avoided in configure.ac. Running autoupdate is advised.
AC_DECL_SYS_SIGLIST.
** Bug Fixes
- Portability of the Autoconf package to Solaris.
- Spurious warnings caused by config.status.
This bug is benign, but painful: on some systems (typically
FreeBSD), warnings such as:
config.status: creating Makefile
mv: Makefile: set owner/group (was: 1357/0): Operation not permitted
could be issued. This is fixed.
- Parallel Builds
Simultaneous executions of config.status are possible again.
- Precious variables accumulation
config.status could stack several copies of the precious variables
assignments.
** Plans for 2.57
- ./configure
The compatibility hooks with the old scheme will be completely
removed. Please, advice/use `--build', `--host', and `--target'
only.
- AC_CHECK_HEADER, AC_CHECK_HEADERS
The tests will be stricter, please make sure your invocations are
valid.
- shell functions
Shell functions will gradually be introduced, probably starting with
Autotest. If you know machines which are in use that you suspect
*not* to support shell functions, please run the test suite of
Autoconf 2.55 on it, and report the results to
[EMAIL PROTECTED]
Re: Automake and no-gzip-dist
Olaf> Hello automake team, Olaf> I'm using Olaf> AM_INIT_AUTOMAKE([foreign 1.5 no-define dist-bzip2]) Olaf> which will create a tar.gz and tar.bz2 dist. How can I prevend Olaf> automake from building the tar.gz dist, since there isn't a Olaf> target like no-gzip-dist. By submitting a patch that implements it :)
Re: ylwrap fails with flex 2.5.4 and prefix
| Hi, | I'm using flex as the lexer, and I'm using flex's | support for prefixes. So when I put a | | %option prefix="dfg_" Use prefix and outfile to please Automake. src/bison/src % fgrep %option scan-gram.l nostromo 9:59 %option debug nodefault noyywrap never-interactive %option prefix="gram_" outfile="lex.yy.c"
Re: automake & flex's -P option
| Hello. Hi! | I recently converted one of my projects to autoconf 2.57 & automake | 1.7.3. I'm not bothered about portability to systems other than | DJGPP or Linux. In particular I've been using switches that are | particular to flex and bison: those to set the prefix of the lexer | and parser's function and varibable names. This works fine with | bison. But not with flex, because it modifies the output file name | from lexyy.c to lexfoo.c. ($LEX_OUTPUT_ROOT == lexyy for DJGPP.) Nope, use %option outfile in addition to %option prefix.
Re: automake & flex's -P option
Richard> But won't that break the automake rules? They expect the lex Richard> output file to be called $LEX_OUTPUT_ROOT. $LEX_OUTPUT_ROOT Richard> is different on Linux than DJGPP (lex.yy vs. lexyy). If I Richard> use %option outfile and %option prefix, it will work on one Richard> platform, but not the other. I thought about getting Richard> config.status to do some substitution on the lexer sources, Richard> but that's just horrible and it means that the user would Richard> have to have (f)lex installed. I think a lot could be done to improve the interface provided that we require Bison and Flex. The problem here stems on the willingness to be yacc/lex portable. Richard> So, back to my original suggestion: Modify the automake Richard> rules to invoke lex with the -t option and pipe the output Richard> to $LEX_OUTPUT_FILE. Then the use -P or %option prefix will Richard> not break the automake rule. But how portable is 'lex -t'? I don't think this is the right track, since flex and bison now generate more that just one file. Relying on something like -o is saner, but stdout is a dead end.
Re: make -j and touching configure.in, with automake
| > Aharon> Thanks Tom. I'll wait for Akim to reply and/or forward to Andre. | > Aharon> Akim, this happens pretty consistently for me with automake 1.7.3, | > Aharon> autoconf 2.57 and current gawk; just touch configure.in in that dist | > Aharon> and type make. | > | > Hi Aharon, | > | > I don't exactly how the dependencies are output but Automake, but the | > "logical" order is indeed running autoconf first. As a matter of | > fact, because there is a cache sharing the results of the runs, it | > shouldn't matter. But running Autoconf and Automake concurrently | > doesn't make a lot of sense, indeed, except if the cache is up to date. | | What happens in a straight run is | | aclocal -I m4 | automake | autoconf | configure --recheck # or whatever it is | | When the first three run in parallel, things go nuts. | | This is real easy to duplicate; get the gawk dist, configure, make. | Then edit the version in configure.in (in both marked places), save | the file, and type `make'. Watch it all fall apart. I don't trust myself on this issue: I don't spend enough time on the Autotools to track this down and fix. I'm Cc'ing this to Automake folks, as they are the one(s) who do currently the real work. Salut le Automake folk :)
Makefileless AC_CONFIG_AUX_DIR
I discovered a nice property of AC_CONFIG_AUX_DIR and (CVS) Automake: you can use the Autoconf macro, and not provide a Makefile.am for this directory. The content is properly shipped, everything works fine, and you saved one AC_CONFIG_FILES, one Makefile.am, one SUBDIRS. I don't know if this is will be preserved, but I would suggest that the decision to support or not to support this feature be specified. If positive, then let's document, if not, let's add a warning somewhere.
Re: Makefileless AC_CONFIG_AUX_DIR
> On Mon, Jun 02, 2003 at 09:09:23AM +0200, Akim Demaille wrote: >> >> I discovered a nice property of AC_CONFIG_AUX_DIR and (CVS) Automake: >> you can use the Autoconf macro, and not provide a Makefile.am for this >> directory. The content is properly shipped, everything works fine, >> and you saved one AC_CONFIG_FILES, one Makefile.am, one SUBDIRS. >> >> I don't know if this is will be preserved > I think this has worked since utomake 1.5 and that this is covered by > the test suite. I'll check tonight to be sure. Where would you like > this to be documented? Next to AC_CONFIG_AUX_DIR :)
Re: tarball checksum/signature targets?
Harlan> Thanks - my goal is to produce some number of checksum files Harlan> (md5, "sum", pgp, gpg, whatever) at the time I produce the Harlan> distribution *balls. Harlan> I'd then "publish" the *balls and checksum files. Harlan> I'm not sure I care about validating this on the user's side Harlan> yet, but I can see that it would be Useful to have utility Harlan> that would compare a *ball with the distributed checksum Harlan> files as well. Have a look at the Coreutils Makefile.maint/GNUMakefile's "alpha" target.
nodist => CLEANFILES, no?
Why wouldn't nodist_ stuff be automatically included into CLEANFILES? I often find myself repeating things because of this.
Re: nodist => CLEANFILES, no?
> On Tue, Jun 24, 2003 at 02:02:25PM +0200, Akim Demaille wrote: >> >> Why wouldn't nodist_ stuff be automatically included into CLEANFILES? > I think it would make sense. > http://www.cygwin.com/ml/bug-automake/2002/msg01693.html I would love this. The only issue is where to bind the cleaning. DISTCLEAN or CLEAN :(
New aclocal happiness message
~/src/tc % make nostromo Err 2 cd . && /bin/sh /home/akim/src/tc/config/missing --run aclocal-1.7a -I config cd . && /bin/sh /home/akim/src/tc/config/missing --run automake-1.7a --foreign /usr/local/bin/m4: config/warning.m4:23: EOF in string autom4te: /usr/local/bin/m4 failed with exit status: 1 It is so great to read the real guilty M4 source, and no longer aclocal.m4... Thanks a lot for this magical change!
Re: nodist => CLEANFILES, no?
> Earnie Boyd wrote: >> Akim Demaille wrote: >> >>> > On Tue, Jun 24, 2003 at 02:02:25PM +0200, Akim Demaille wrote: >>> >> >> Why wouldn't nodist_ stuff be automatically included into >>> CLEANFILES? >>> >>> > I think it would make sense. >>> >>> > http://www.cygwin.com/ml/bug-automake/2002/msg01693.html >>> >>> I would love this. The only issue is where to bind the >>> cleaning. DISTCLEAN or CLEAN :( >>> >> Me thinks, DISTCLEAN the better choice. > Me too, since sometimes nodist_ files are created by configure, not make. Actually, this does not fit my needs, since my files are "make" files, not "configure" files. But how about making automake even smarter? 1. AC_CONFIG_FILES etc. are to be DISTCLEANED (aren't they already?) 2. nodist_ and target of a rule => CLEAN
Re: nodist => CLEANFILES, no?
>> But how about making automake even smarter? >> 1. AC_CONFIG_FILES etc. are to be DISTCLEANED (aren't they already?) >> 2. nodist_ and target of a rule => CLEAN > What if the file is in both? I have package-config file which is > generated by configure (AC_CONFIG_FILES) and then installed via > nodist_bin_SCRIPTS. That's not both, it's only the first one: it is not one of your target.
ICC 7.0 and distcc
| But when I used distcc, all is lost with the -MD flags
|
| | /tmp % distcc /home/lrde/lrde/usr/bin/icc -Kc++ error.cc -c nostromo 18:58
| | error.cc(2): error: function "foo" has already been defined
| | int foo () { return 1;}
| | ^
| |
| | compilation aborted for /tmp/distcc_106/server_031068.ii (code 2)
| | distcc[31066] ERROR: compile on nostromo failed with exit code 2
| | /tmp % distcc /home/lrde/lrde/usr/bin/icc -Kc++ error.cc -c -MD -MF foo.Po
| | /tmp %
|
|
| If someone has an idea...
Actually, I'm not sure one can get both a CPP output together with
dependencies. Distcc wants -E, and Automake wants -MD -MF:
-M generate makefile dependency information
-MMsimilar to -M, but do not include system header files
-MGsimilar to -M, but treat missing header files as generated files
-MDpreprocess and compile, generating output file containing
dependency information ending with extension .d
-MMD similar to -MD, but do not include system header files
-MF generate makefile dependency information in file (must specify -M
or -MM)
It results in:
/tmp % cat correct.ccnostromo 19:21
int foo () { return 1;}
/tmp % /home/lrde/lrde/usr/bin/icc -Kc++ -E correct.cc nostromo 19:22
#line 1 "correct.cc"
int foo () { return 1;}
/tmp % /home/lrde/lrde/usr/bin/icc -Kc++ -E -MD -MFoutput.d correct.cc
/tmp % cat output.d nostromo 19:22
correct.o: correct.cc
I did not find a means to get the -E part...
/tmp % /home/lrde/lrde/usr/bin/icc -Kc++ -MD -MFoutput.d -E -o output.i correct.cc
/tmp % cat output.i nostromo 19:23
cat: output.i: No such file or directory
ICC 7.0 and distcc
I make some progress understanding why I find it hard to use Icc with
distcc. I face several problems, some of them might be already known.
Currently, I use the following wrapper to make sure Icc understands
what .ii is about:
/tmp % cat =icc nostromo 18:54
#! /bin/sh
# ICC needs to be taught that *.ii is C++.
# The wonderful news is that:
#
# % /home/lrde/lrde/usr/bin/icc I-dont-exist
# ld: cannot open I-dont-exist: No such file or directory
# % /home/lrde/lrde/usr/bin/icc -c I-dont-exist
#
# icc per se does not complain about missing files... That's
# why understanding the problems takes so long
case "$@" in
*.cc*|*.cpp*) set -- -Kc++ "$@" ;;
esac
exec /usr/bin/distcc /home/lrde/lrde/usr/bin/icc "$@"
But I face another problem, related to Automake's depcomp. I don't
know if the issue is known:
| /tmp % cat error.cc nostromo 18:55
| int foo () { return 1;}
| int foo () { return 1;}
A broken source.
| /tmp % /home/lrde/lrde/usr/bin/icc error.cc -c nostromo 18:55
| error.cc(2): error: function "foo" has already been defined
| int foo () { return 1;}
| ^
An expected failure when attacking directly the compiler.
| /tmp % /home/lrde/lrde/usr/bin/icc error.cc -c -MD -MF foo.Po nostromo Err 2
| error.cc(2): error: function "foo" has already been defined
| int foo () { return 1;}
| ^
Likewise with Automake's flags to compute the dependencies.
But when I used distcc, all is lost with the -MD flags
| /tmp % distcc /home/lrde/lrde/usr/bin/icc -Kc++ error.cc -c nostromo 18:58
| error.cc(2): error: function "foo" has already been defined
| int foo () { return 1;}
| ^
|
| compilation aborted for /tmp/distcc_106/server_031068.ii (code 2)
| distcc[31066] ERROR: compile on nostromo failed with exit code 2
| /tmp % distcc /home/lrde/lrde/usr/bin/icc -Kc++ error.cc -c -MD -MF foo.Po
| /tmp %
If someone has an idea...
Re: Icc 7.0, distcc, Automake
For the records, I'm using the following script. It results in a correct compilation with Automake, Icc, and Distcc. #! /bin/sh icc=/home/lrde/lrde/usr/bin/icc # ICC needs to be taught that *.ii is C++. # The wonderful news is that: # # % /home/lrde/lrde/usr/bin/icc I-dont-exist # ld: cannot open I-dont-exist: No such file or directory # % /home/lrde/lrde/usr/bin/icc -c I-dont-exist # # icc per se does not complain about missing files... That's # why understanding the problems takes so long case "$@" in *.cc*|*.cpp*) set -- -Kc++ "$@" ;; esac # ICC is not able to honor both -E and -M, but Automake wants -M, # and -E will be added by distcc. case "$@" in *-M*) # Push a token among the arguments that will be used to notice when we # ended options/arguments parsing. arg_sep="$$--$$" set -- "$@" "$arg_sep" # # Parse command line arguments. while test x"$1" != x"$arg_sep"; do case "$1" in -MF) shift minus_M_args="$minus_M_args -MF$1" ;; -M*) minus_M_args="$minus_M_args $1" ;; -E) minus_E=-E;; *) set -- "$@" "$1";; esac shift done # Pop the token shift ;; esac if test "x$minus_E" != x; then echo "$0: don't know what to do with -E" >&2 fi if test "x$minus_M_args" != x; then $icc $minus_M_args "$@" fi exec /usr/bin/distcc $icc "$@" But the speedup is really miserable: none AFAICS (on several runs). I must say that my src hierarchy is poor for -j, as it heavily uses Automake and many small modules compiled sequentially. Here are the figure I get: make -j4 CC=icc CXX=icc 250,09s user 17,22s system 46% cpu 9:38,68 total make -j4 CC=dicc CXX=dicc 257,89s user 22,69s system 55% cpu 8:22,51 total
Re: icc dependency generation
> On Thu, Jun 26, 2003 at 11:23:04AM +0200, Ralf Wildenhues wrote: >> Intel compiler icc version 7.1 handles the -MF option inconsistently. >> Documentation states that it has to be used together with -M or -MM. >> If used with -MD, for example, it will replace the file ending with .d: > [...] >> Subsequently, the depcomp 'icc' mode will not be detected correctly >> during the ./configure run, since it uses '-MD -MF'. > This sucks. If -MF cannot work with -MD, depcomp will have to call icc > twice: one time to get dependency information, and another time to do > the actual compilation. This will be slower. > Or we could use -MD alone, but as ICC does respect subdirectories (at > least with ICC 7.0, compiling foo/bar.c with -MD would create ./bar.d > instead of foo/bar.d -- could you check this with 7.1?) we'd need to > implement some locking scheme in depcomp so that compiling foo/bar.c > and baz/bar.c in parallel do not write the same bar.d. >> Any suggestions? > Complain to Intel, if not already done. >> Which compiler version is the current depcomp supposed >> to work with? > 7.0 Err, maybe my message went unnoticed, but you might find additional information here too. From: Akim Demaille <[EMAIL PROTECTED]> Subject: Re: Icc 7.0, distcc, Automake To: [EMAIL PROTECTED] cc: Automake List <[EMAIL PROTECTED]> Date: Thu, 26 Jun 2003 11:01:12 +0200 X-Sent: 3 hours, 45 minutes, 35 seconds ago For the records, I'm using the following script. It results in a correct compilation with Automake, Icc, and Distcc. [4. text/x-sh; dicc] #! /bin/sh icc=/home/lrde/lrde/usr/bin/icc # ICC needs to be taught that *.ii is C++. # The wonderful news is that: # # % /home/lrde/lrde/usr/bin/icc I-dont-exist # ld: cannot open I-dont-exist: No such file or directory # % /home/lrde/lrde/usr/bin/icc -c I-dont-exist # # icc per se does not complain about missing files... That's # why understanding the problems takes so long case "$@" in *.cc*|*.cpp*) set -- -Kc++ "$@" ;; esac # ICC is not able to honor both -E and -M, but Automake wants -M, # and -E will be added by distcc. case "$@" in *-M*) # Push a token among the arguments that will be used to notice when we # ended options/arguments parsing. arg_sep="$$--$$" set -- "$@" "$arg_sep" # # Parse command line arguments. while test x"$1" != x"$arg_sep"; do case "$1" in -MF) shift minus_M_args="$minus_M_args -MF$1" ;; -M*) minus_M_args="$minus_M_args $1" ;; -E) minus_E=-E;; *) set -- "$@" "$1";; esac shift done # Pop the token shift ;; esac if test "x$minus_E" != x; then echo "$0: don't know what to do with -E" >&2 fi if test "x$minus_M_args" != x; then $icc $minus_M_args "$@" fi exec /usr/bin/distcc $icc "$@" But the speedup is really miserable: none AFAICS (on several runs). I must say that my src hierarchy is poor for -j, as it heavily uses Automake and many small modules compiled sequentially. Here are the figure I get: make -j4 CC=icc CXX=icc 250,09s user 17,22s system 46% cpu 9:38,68 total make -j4 CC=dicc CXX=dicc 257,89s user 22,69s system 55% cpu 8:22,51 total --
Re: distdir.am v1.47
> I am getting
> sed: 1: "1{h;s/./=/g;p;x}": extra characters at the end of x command
> gmake: *** [distcheck] Error 1
> which I think comes from
> RCS file: /cvs/automake/automake/lib/am/distdir.am,v
> retrieving revision 1.46
> retrieving revision 1.47
> diff -r1.46 -r1.47
> ...
> 348,350c351,353
> < $(am__remove_distdir)
> < @echo "$(distdir).tar.gz is ready for distribution" | \
> < sed 'h;s/./=/g;p;x;p;x'
> ---
>> @(echo "$(distdir) archives ready for distribution: "; \
>> for i in $(DIST_ARCHIVES); do echo $$i; done) | \
>> sed -e '1{h;s/./=/g;p;x}' -e '$${p;x}'
> This seems to make my NetBSD sed unhappy... Thoughts?
I'm installing the following.
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* lib/am/distdir.am: Use ';' as a terminator, not a separator, for
sed complex commands, as required by NetBSD sed.
Reported by Patrick Welche.
Index: Makefile.in
===
RCS file: /cvs/automake/automake/Makefile.in,v
retrieving revision 1.438
diff -u -u -r1.438 Makefile.in
--- Makefile.in 3 Jul 2003 18:58:49 - 1.438
+++ Makefile.in 5 Jul 2003 08:21:36 -
@@ -585,7 +585,7 @@
$(am__remove_distdir)
@(echo "$(distdir) archives ready for distribution: "; \
list='$(DIST_ARCHIVES)'; for i in $$list; do echo $$i; done) | \
- sed -e '1{h;s/./=/g;p;x}' -e '$${p;x}'
+ sed -e '1{h;s/./=/g;p;x;}' -e '$${p;x;}'
distuninstallcheck:
@cd $(distuninstallcheck_dir) \
&& test `$(distuninstallcheck_listfiles) | wc -l` -le 1 \
Index: stamp-vti
===
RCS file: /cvs/automake/automake/stamp-vti,v
retrieving revision 1.252
diff -u -u -r1.252 stamp-vti
--- stamp-vti 4 Jul 2003 22:13:52 - 1.252
+++ stamp-vti 5 Jul 2003 08:21:36 -
@@ -1,4 +1,4 @@
[EMAIL PROTECTED] UPDATED 4 July 2003
[EMAIL PROTECTED] UPDATED 5 July 2003
@set UPDATED-MONTH July 2003
@set EDITION 1.7a
@set VERSION 1.7a
Index: version.texi
===
RCS file: /cvs/automake/automake/version.texi,v
retrieving revision 1.324
diff -u -u -r1.324 version.texi
--- version.texi 4 Jul 2003 22:13:52 - 1.324
+++ version.texi 5 Jul 2003 08:21:36 -
@@ -1,4 +1,4 @@
[EMAIL PROTECTED] UPDATED 4 July 2003
[EMAIL PROTECTED] UPDATED 5 July 2003
@set UPDATED-MONTH July 2003
@set EDITION 1.7a
@set VERSION 1.7a
Index: lib/am/distdir.am
===
RCS file: /cvs/automake/automake/lib/am/distdir.am,v
retrieving revision 1.49
diff -u -u -r1.49 distdir.am
--- lib/am/distdir.am 2 Jul 2003 20:53:07 - 1.49
+++ lib/am/distdir.am 5 Jul 2003 08:21:36 -
@@ -351,7 +351,7 @@
$(am__remove_distdir)
@(echo "$(distdir) archives ready for distribution: "; \
list='$(DIST_ARCHIVES)'; for i in $$list; do echo $$i; done) | \
- sed -e '1{h;s/./=/g;p;x}' -e '$${p;x}'
+ sed -e '1{h;s/./=/g;p;x;}' -e '$${p;x;}'
## Define distuninstallcheck_listfiles and distuninstallcheck separately
## from distcheck, so that they can be overridden by the user.
Re: INSTALL_SCRIPT
> On Tue, 2003-07-15 at 08:57, Ralf Corsepius wrote: >> On Tue, 2003-07-15 at 08:25, Alexandre Duret-Lutz wrote: >> I'll try to contact the original reporter, but currently would assume >> this to be a local bug in the package or a miss-understanding by the >> original reporter. > This problem seemed to be caused by a broken install script reportedly > shipped with OpenAFS, the user accidentally had in $PATH. > For the full story, cf. > http://www.oarcorp.com/rtems/maillistArchives/rtems-users/2003/july/msg00053.html Isn't this another clear sign that the existing AC_PROG_INSTALL is pure junk? That we should really test for the feature we _desire_, i.e., "install FILES DIR".
Autoconf 2.57b released
rm -f autoconf-2.57b.tar.bz2.asc
gpg --armor --detach-sign -o autoconf-2.57b.tar.bz2.asc autoconf-2.57b.tar.bz2
rm -f autoconf-2.57b.tar.gz.asc
gpg --armor --detach-sign -o autoconf-2.57b.tar.gz.asc autoconf-2.57b.tar.gz
<#secure method=pgpmime mode=sign>
The team is happy to make a long overdue step forward a release of
Autoconf 2.58. Unfortunately, many of the submitted new features will
not make it into the next release, but, if time permits, one may
expect a 2.59 to include these.
Because Automake 1.8 is making significant progress, because it needs
Autoconf to fix some issue, 2.58 should be released in the near future.
Please, test it intensively.
I invite the people who participated to this release to submit some
NEWS.
Note that:
- I'm new to this release process, so there is plenty of information
on this generated template announcement I'm not sure what I should
do with (such as the four first lines). Ignore them...
- My Fencepost account is not reactivated yet, so you might have to
download from
http://www.lrde.epita.fr/~akim/download/autoconf-2.57b.tar.gz (1.1MB)
http://www.lrde.epita.fr/~akim/download/autoconf-2.57b.tar.bz2 (836KB)
Enjoy!
Akim, Alexandre, Jim, Paul, and Tom.
--
Here are the compressed sources:
ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.57b.tar.gz (1.1MB)
ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.57b.tar.bz2 (836KB)
And here are xdelta-style diffs:
ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.57a-2.57b.xdelta (37KB)
Here are GPG detached signatures:
ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.57b.tar.gz.asc
ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.57b.tar.bz2.asc
Here are the MD5 and SHA1 signatures:
938f2f34126a9f243c6613ad86f4c117 autoconf-2.57b.tar.gz
3e5b20067bcc34b4621c35f7b517f1c4 autoconf-2.57b.tar.bz2
af930258b7157194b930c2abe5fae706 autoconf-2.57a-2.57b.xdelta
dff9f703b12a8d2d0db5f2aa01fac3734d35c0c5 autoconf-2.57b.tar.gz
c2a8c7e1ae802ae202ce1e0439413e100e43b1c9 autoconf-2.57b.tar.bz2
10b6db255bbb5e97821f15f195d08b1c888d0edc autoconf-2.57a-2.57b.xdelta
NEWS
* Major changes in Autoconf 2.57b -*- outline -*-
** Autotest and local.at
The optional file local.at is always included in Autotest test suites.
** Warnings
The warnings are always issued, including with cached runs.
This became a significant problem since aclocal and automake can
run autoconf behind the scene.
ChangeLog entries:
**
ChangeLog
******
2003-08-22 Akim Demaille <[EMAIL PROTECTED]>
Version 2.57b.
* Makefile.cfg (local-checks-to-skip): New.
* Makefile.maint (local-check): Rename as...
(local-checks-available): this.
(local-check): New.
* Makefile.am (EXTRA_DIST): Add Makefile.cfg.
* configure.ac: Require Automake 1.7.6.
2003-08-22 Akim Demaille <[EMAIL PROTECTED]>
Output stack traces in warnings.
* lib/m4sugar/m4sugar.m4 (_m4_warn): New.
Replace the former...
(m4_warn): Pass the call stack to _m4_warn.
* bin/autom4te.in: Adjust to output the call stack.
* tests/m4sugar.at (m4@&[EMAIL PROTECTED]): Adjust.
2003-08-22 Akim Demaille <[EMAIL PROTECTED]>
* lib/Autom4te/Request.pm, lib/Autom4te/C4che.pm: New.
* bin/autom4te.in: Adjust.
2003-08-21 Akim Demaille <[EMAIL PROTECTED]>
* lib/Autom4te/General.pm (&file_name_is_absolute): Remove.
(&verbose): Remove.
(&getopt): Adjust the note and verb channels, depending upon
--verbose.
* bin/autoheader.in, bin/autom4te.in, bin/autoscan.in,
* bin/autoupdate.in: Adjust.
Use &verb, not &verbose.
2003-08-21 Akim Demaille <[EMAIL PROTECTED]>
* bin/autoheader.in (&parse_args): Use &parse_warnings and
&parse_WARNINGS.
($help): Use Autom4te::ChannelDefs::usage.
* bin/autoscan.in: Use Autom4te::ChannelDefs.
* lib/Autom4te/General.pm: Don't export error: you don't own it.
2003-08-21 Akim Demaille <[EMAIL PROTECTED]>
First stab at preserving warnings between calls to autom4te,
including when the cache is used.
There are still several issues: (i) there are too many runs of m4
(one for include, one for warnings, and some more), (ii) warnings
spreading on several lines are not handled gracefully, (iii) the
code meant to have the call stack display for errors does not work
(its handling should move from m4 to autom4te).
* bin/autom4te.in Autom4te::Channels, Autom4te::ChannelDefs):
Use them.
(@preselect): Add m4_warn.
($exit_status): Remove, use $exit_code.
Re: txinfo trivial failures
Alexandre:
> Texi2dvi runs something like
> tex --help &1
> On your system it seems to print "fflush error on stdout" and create
> texput.log as a side effect. On mine it works just fine (i.e. it
> prints the help -- I have TeX (Web2C 7.4.5) 3.14159).
> So I think texi2dvi should be changed to clean texput.log
> afterwards (or run tex --help in a temporary directory).
I suggest this patch, which includes another one pending for Texinfo.
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
Workaround a TeX bug: --file-line-error-style '\nonstopmode'
does not honor the non stop mode request.
Also, make sure 'tex --help' is run in tmp to avoid leaving
texput.log.
* util/texi2dvi (tex_help): New.
(tex_args): Instead of using '\nonstopmode', pass
'--interaction=nonstopmode'.
Index: util/texi2dvi
===
RCS file: /cvsroot/texinfo/texinfo/util/texi2dvi,v
retrieving revision 1.24
diff -u -u -r1.24 texi2dvi
--- util/texi2dvi 2 Jul 2003 14:23:28 - 1.24
+++ util/texi2dvi 22 Aug 2003 08:15:55 -
@@ -491,15 +491,21 @@
;;
esac
+ # Not all TeX handle --help gracefully.
+ tex_help=`cd $tmpdir >/dev/null && $tex --help &1`
+
# If possible, make TeX report error locations in GNU format.
tex_args=
- case `$tex --help &1` in
- *file-line-error-style*) tex_args='--file-line-error-style';;
+ case $tex_help in
+ *file-line-error-style*) tex_args="$tex_args --file-line-error-style";;
esac
# Tell TeX to be batch if requested. (\batchmode does not show
# terminal output at all, so we don't want that.)
- $batch && tex_args="$tex_args ${escape}nonstopmode ${escape}input"
+ $batch &&
+case $tex_help in
+ *interaction*) tex_args="$tex_args --interaction=nonstopmode";;
+esac
# Expand macro commands in the original source file using Makeinfo.
# Always use `end' footnote style, since the `separate' style
Re: Help - I'm going mad!!! /bin/bash: --gnu: command not found
> %% "Dr. David Kirkby" <[EMAIL PROTECTED]> writes: dk> make[1]: Entering directory `/export/home/davek/atlc/src' dk> cd .. && \ dk> --gnu src/Makefile dk> /bin/bash: --gnu: command not found This mean AUTOMAKE is empty.
Re: Variable substitution in source files
> I have a number of files that need variable substitution, so I do this in > a Makefile.am: > foo: foo.in > @rm -f foo > @sed \ > -e 's,@@perlmoduledir@@,$(libexecdir)/perl,' \ > -e 's,@@swishbindir@@,$(bindir),' \ > -e 's,@@perlbinary@@,$(PERL),' \ > $(srcdir)/foo.in > foo > But I'm doing that in more and more Makefile.am files in my project > tree -- and sometimes I need to do it to a file where there isn't a > Makefile in that directory. > I'm feeling like I'm using the same bit of sed code in too many places. > Is there a better way to manage this? I'd like to have the sed code > (above) defined in one place and then maybe list all the files that need > to be operated on. Use "include"?
Re: Copying vs m4_including macro files
>> The autoconf part of this feature is trivial (I can provide a patch if >> that's useful), but I suspect I'd need to be able to write perl to >> implement the aclocal end :-) > Fortunately, if we consider relative directories as local, we don't > need to look at AC_CONFIG_M4_DIR. Adding this macro to Autoconf is > probably a good thing for the future, though. At the origin I was considering that AC_CONFIG_M4_DIR was automatically passed to m4 as a -I, so instead of m4_include([config/init.m4]) etc. you'd have m4_include([init.m4]).
Re: Copying vs m4_including macro files
> On Wed, Sep 24, 2003 at 02:19:06PM +0200, Akim Demaille wrote: >> At the origin I was considering that AC_CONFIG_M4_DIR was >> automatically passed to m4 as a -I, so instead of >> m4_include([config/init.m4]) etc. you'd have m4_include([init.m4]). > Isn't there a chicken'n'egg problem? How can you trace for > AC_CONFIG_M4_DIR if you need the result to run m4 properly? Right, there was something like that :)
Should -i mkdir?
Several projects used config/ without any hand written file in it, thanks to Automake's wonderful ability to ship the files all by itself. But then, often, such projects, when just checked out, or de-tar'ed by hand, don't have a config/. Et soudain, c'est l'accident : ~/src/vampire % autoreconf -fvi nostromo 9:55 autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/local/bin/autoconf --force autoreconf: configure.ac: not using Autoheader autoreconf: running: automake --add-missing --copy --force-missing cp: cannot create regular file `config/install-sh': No such file or directory configure.ac: installing `config/install-sh' configure.ac: error while copying cp: cannot create regular file `config/mkinstalldirs': No such file or directory configure.ac: installing `config/mkinstalldirs' configure.ac: error while copying cp: cannot create regular file `config/missing': No such file or directory configure.ac: installing `config/missing' configure.ac: error while copying cp: cannot create regular file `config/mdate-sh': No such file or directory doc/texinfo/Makefile.am:20: installing `config/mdate-sh' doc/texinfo/Makefile.am:20: error while copying cp: cannot create regular file `config/texinfo.tex': No such file or directory doc/texinfo/Makefile.am:20: installing `config/texinfo.tex' doc/texinfo/Makefile.am:20: error while copying autoreconf: automake failed with exit status: 1 So, should automake -i make sure the directory exists and create it if needed? Or that would be considered unsafe (a typo in the name, et voilà , a nasty dir pollutes your codeshore).
Autoconf 2.57d released
<#secure method=pgpmime mode=sign>
This is our candidate release for Autoconf 2.58. We plan to release
it soon, so that Automake 1.8 can be released, hence Libtool 1.6, so
that GNU M4 2.0 can be shipped, enabling Autoconf 2.60 ;)
Please, test it thoroughly.
Akim, Alexandre, Jim, Paul, and Tom.
Here are the compressed sources:
http://www.lrde.epita.fr/~akim/download/autoconf-2.57d.tar.gz (1.2MB)
http://www.lrde.epita.fr/~akim/download/autoconf-2.57d.tar.bz2 (837KB)
And here are xdelta-style diffs:
http://www.lrde.epita.fr/~akim/download/autoconf-2.57b-2.57d.xdelta (26KB)
Here are GPG detached signatures:
http://www.lrde.epita.fr/~akim/download/autoconf-2.57d.tar.gz.asc
http://www.lrde.epita.fr/~akim/download/autoconf-2.57d.tar.bz2.asc
Here are the MD5 and SHA1 signatures:
2fd6b2ce93c20272114580696b873b13 autoconf-2.57d.tar.gz
11283066884ee9dac83b9e6d9a7870f4 autoconf-2.57d.tar.bz2
f1bf3224ee351de53229c8e3957ac888 autoconf-2.57b-2.57d.xdelta
810ea71de4c866970f76079036847c63ad605d77 autoconf-2.57d.tar.gz
be65e491f94df9e1fa0aa272df78848d0ef2ac84 autoconf-2.57d.tar.bz2
92306a504a352c140c7795839cfe374f7e931046 autoconf-2.57b-2.57d.xdelta
NEWS
* Major changes in Autoconf 2.57d
* Major changes in Autoconf 2.57b
Released 2003-08-24, by Akim Demaille.
** Autotest and local.at
The optional file local.at is always included in Autotest test suites.
** Warnings
The warnings are always issued, including with cached runs.
This became a significant problem since aclocal and automake can
run autoconf behind the scene.
** autoheader warnings
The warnings of autoheader can be turned off, using --warning.
For instance, -Wno-obsolete disables the complaints about acconfig.h
and other deprecated constructs.
* Major changes in Autoconf 2.57a
** New macros
AC_C_RESTRICT, AC_INCLUDES_DEFAULT.
** AC_DECL_SYS_SIGLIST
Works again.
** AC_FUNC_MKTIME
Now checks that mktime is the inverse of localtime.
** Improve DJGPP portability
The Autoconf tools and configure behave better under DJGPP.
** Present But Cannot Be Compiled
New FAQ section dedicated to the mystic
configure: WARNING: pi.h: present but cannot be compiled
configure: WARNING: pi.h: check for missing prerequisite headers?
configure: WARNING: pi.h: proceeding with the preprocessor's result
messages.
** Concurrent executions of autom4te
autom4te now locks its internal files, which enables concurrent
executions of autom4te, likely to happen if automake, autoconf,
autoheader etc. are run simultaneously.
** Libtool
Use of Libtool 1.5 and higher is encouraged. Compatibility with
Libtool pre-1.4 is not checked.
** Autotest
Testsuites no longer rerun failed tests in verbose mode; instead,
failures are logged while the test is run.
In addition, expected failures can be marked as such.
ChangeLog entries:
**
ChangeLog
**
2003-09-25 Akim Demaille <[EMAIL PROTECTED]>
Version 2.57d.
* bin/Makefile.am (edit): Handle '@configure_input@'.
(autoconf, autoheader, autom4te, autoreconf, autoscan, autoupdate)
(ifnames): chmod -w.
* tests/wrapper.as (AUTOCONF, AUTOM4TE, ): Point to tests/
executables, not bin/ executables! Otherwise all the magic needed
to find non installed files is turned off. This caused a failure
of test 40 and 41 that ran aclocal 1.8 which in turn ran autom4te
as found in its environment (sent by tests/autoreconf): pointing
to bin/autom4te that could not find its files.
* tests/mktests.sh: Force the replacement of generated files, for
the sake of "mv" program that are interactive when overwriting a
-w file.
* config/install-sh: Upgrade from CVS Automake.
2003-09-23 Paul Eggert <[EMAIL PROTECTED]>
* doc/autoconf.texi (Limitations of Builtins): Document test -h
versus test -L issues.
2003-09-23 Daniel Jacobowitz <[EMAIL PROTECTED]> and
Paul Eggert <[EMAIL PROTECTED]>
Trivial change to support GCC's configuration procedure.
* lib/autoconf/c.m4 (AC_PROG_CPP_WERROR): New macro.
* lib/autoconf/headers.m4 (_AC_CHECK_HEADER_MONGREL): Don't warn
about inconsistency if the preprocessor is set to give errors for
any warning.
* doc/autoconf.texi (C Compiler Characteristics): Document this.
2003-09-13 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* Makefile.am (autom4te-update, autom4te_files): Fetch Struct.pm
and XFile.pm from Automake.
* lib/Autom4te/XFile.pm: Update from Automake.
2003-09-12 Akim Demaille <[EMAIL PROTECTED]>
Version 2.57c.
2003-09-12 Akim Demaille <[EMAIL PROTECTED]>
* config/config.guess,
Autoconf 2.57f is released
This is our candidate release for Autoconf 2.58. We plan to release
it soon, so that Automake 1.8 can be released, hence Libtool 1.6, so
that GNU M4 2.0 can be shipped, enabling Autoconf 2.60 ;)
Please, test it thoroughly.
Akim, Alexandre, Jim, Paul, and Tom.
Here are the compressed sources:
http://www.lrde.epita.fr/~akim/download/autoconf-2.57f.tar.gz (1.2MB)
http://www.lrde.epita.fr/~akim/download/autoconf-2.57f.tar.bz2 (837KB)
And here are xdelta-style diffs:
http://www.lrde.epita.fr/~akim/download/autoconf-2.57d-2.57f.xdelta (10KB)
Here are GPG detached signatures:
http://www.lrde.epita.fr/~akim/download/autoconf-2.57f.tar.gz.asc
http://www.lrde.epita.fr/~akim/download/autoconf-2.57f.tar.bz2.asc
Here are the MD5 and SHA1 signatures:
dd48fe8cf425f7068d729aa432df4527 autoconf-2.57f.tar.gz
385a923859a0e02e4c6f0ccc4f29b137 autoconf-2.57f.tar.bz2
4f342dbfbcee2648e7426c3f46f59fb8 autoconf-2.57d-2.57f.xdelta
9b1f3a2bfeb21e80813619e86cc5a52b7edaffbb autoconf-2.57f.tar.gz
5dd5018ae395ed627384caf69460fea5006a037e autoconf-2.57f.tar.bz2
2cda92c4f05799ace152744927152a1645030287 autoconf-2.57d-2.57f.xdelta
NEWS
* Major changes in Autoconf 2.57f
Released 2003-10-01, by Akim Demaille.
* Major changes in Autoconf 2.57e
Released 2003-09-29, by Akim Demaille.
** AC_CONFIG_COMMANDS
The directory for its first argument is automatically created. For
instance, with
AC_CONFIG_COMMANDS([src/modules.hh], [...])
$top_builddir/src/ is created if needed.
ChangeLog entries:
**
ChangeLog
**
2003-10-01 Akim Demaille <[EMAIL PROTECTED]>
Version 2.57f.
2003-09-30 Paul Eggert <[EMAIL PROTECTED]>
* lib/Autom4te/XFile.pm: Use Errno.
(lock): Ignore ENOLCK errors. Problem reported Andreas Schwab in
<http://mail.gnu.org/archive/html/bug-autoconf/2003-09/msg00141.html>.
2003-09-30 Akim Demaille <[EMAIL PROTECTED]>
* config/announce-gen (&print_news_deltas): Extracted from...
(&print_changelog_deltas): here.
(&news_file): Rename as...
(@news_file): this.
2003-09-30 Nicolas Joly <[EMAIL PROTECTED]>
* lib/autoconf/fortran.m4 (_AC_PROG_FC): Remove files which might
have been created when invoking the compiler.
* tests/fortran.at (GNU Fortran 77): Quote $G77.
2003-09-29 Akim Demaille <[EMAIL PROTECTED]>
Version 2.57e.
* config/mkinstalldirs: Upgrade.
2003-09-28 Paul Eggert <[EMAIL PROTECTED]>
* lib/m4sugar/m4sh.m4 (AS_SHELL_SANITIZE): Set DUALCASE=1, for MKS sh.
Problem reported by Lars J. Aas in
<http://mail.gnu.org/archive/html/autoconf/2003-07/msg00042.html>.
(_AS_MKDIR_P_PREPARE): Change "rm -fr ./-p" to the more-conservative
"test -d ./-p && rmdir ./-p". Suggested by Andreas Schwab in:
http://mail.gnu.org/archive/html/autoconf-patches/2003-09/msg00039.html
2003-09-26 Akim Demaille <[EMAIL PROTECTED]>
* lib/autoconf/status.m4 (_AC_OUTPUT_COMMANDS): Make sure the
directory for AC_CONFIG_COMMANDS' first argument exists.
This makes valid the invocation of _AC_SRCPATH that follows.
Reported by Eric Sunshine.
* doc/autoconf.texi (Configuration Commands): Adjust.
2003-09-26 Akim Demaille <[EMAIL PROTECTED]>
* bin/autoscan.in (Autom4te::FileUtils): Use it for find_file.
Reported by Ralf Corsepius.
2003-09-26 Akim Demaille <[EMAIL PROTECTED]>
* lib/autoconf/general.m4 (AC_HELP_STRING): Don't overquote the
arguments.
Actually, use AU_ALIAS.
From Bruno Haible.
2003-09-26 Paul Eggert <[EMAIL PROTECTED]>
* lib/m4sugar/m4sh.m4 (_AS_MKDIR_P_PREPARE): If mkdir -p . fails,
rm -fr ./-p to remove junk left behind on NextStep and OpenStep.
Problem reported by Eric Sunshine in:
http://mail.gnu.org/archive/html/autoconf-patches/2002-12/msg00014.html
2003-09-26 Akim Demaille <[EMAIL PROTECTED]>
The test suite are sometimes assigning timings incorrectly.
Reported by Henk Krus.
Diagnosed by Nicolas Joly.
* lib/autotest/general.m4 (AT_CLEANUP): Rename AT_help as
AT_help_all.
Instead of making AT_help a sequence of assignments to grow
$at_help_all, just make AT_help_all be the growing contents of
$at_help_all, and make a single assignment in...
(AT_INIT): here.
(at_times_skip): Flip the meaning and rename as...
(at_times_p): this.
(AT_INIT): When summarizing the test that ran, remove
$at_times_file after use, and check it is present before trying to
use it.
Re: Thanks for real good thing!
> Hello, GNU autotools contributors! > Im just ajust my package for realy good building. And I would like to > thank you for realy powerful and useful tool :) This is probably the wrong list: you are probably not referring to the Autotools: Autoconf, Automake, and Libtool. Or else, you're one of a kind :)
Re: Should -i mkdir?
> On Sat, 2003-09-27 at 02:20, Alexandre Duret-Lutz wrote:
adl> autopoint and libtoolize usually run before automake
adl> and put things into this directory too. So if some tools has to
adl> create the directory, I think it should be autopoint.
>>
>> Sorry, I meant "it should be autoreconf".
> /if it's used/
I'm installing the following. Thanks.
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* lib/autom4te.in (Autoreconf-preselections): Trace AC_CONFIG_AUX_DIR.
* bin/autoreconf.in (autoreconf_current_directory): Create the
AUX_DIR if needed, for sake of automake --add-missing etc.
Suggested by Alexandre Duret-Lutz.
Index: NEWS
===
RCS file: /cvsroot/autoconf/autoconf/NEWS,v
retrieving revision 1.311
diff -u -u -r1.311 NEWS
--- NEWS 1 Oct 2003 10:29:39 - 1.311
+++ NEWS 3 Oct 2003 07:28:59 -
@@ -1,4 +1,10 @@
-* Major changes in Autoconf 2.57f -*- outline -*-
+* Major changes in Autoconf 2.57g -*- outline -*-
+
+** autoreconf and auxiliary directory
+ Autoreconf creates the auxiliary directory if needed. This is
+ especially useful for initial "bootstrapping" of fresh CVS checkouts.
+
+* Major changes in Autoconf 2.57f
Released 2003-10-01, by Akim Demaille.
Index: bin/autoreconf.in
===
RCS file: /cvsroot/autoconf/autoconf/bin/autoreconf.in,v
retrieving revision 1.119
diff -u -u -r1.119 autoreconf.in
--- bin/autoreconf.in 25 Aug 2003 06:38:39 - 1.119
+++ bin/autoreconf.in 3 Oct 2003 07:28:59 -
@@ -423,6 +423,7 @@
# Perform a single trace reading to avoid --force forcing a rerun
# between two --trace, that's useless. If there is no AC_INIT, then
# we are not interested: it looks like a Cygnus thingy.
+ my $aux_dir;
my $uses_gettext_via_traces;
my $uses_libtool;
my $uses_autoheader;
@@ -433,6 +434,7 @@
. join (' --trace=', '',
# If you change this list, update the
# `Autoreconf-preselections' section of autom4te.in.
+'AC_CONFIG_AUX_DIR:AC_CONFIG_AUX_DIR:\$1',
'AC_CONFIG_HEADERS',
'AC_CONFIG_SUBDIRS:AC_CONFIG_SUBDIRS:\$1',
'AC_INIT',
@@ -442,6 +444,7 @@
. ' |');
while ($_ = $traces->getline)
{
+ $aux_dir = $1 if /AC_CONFIG_AUX_DIR:(.*)/;
$uses_autoconf = 1if /AC_INIT/;
$uses_gettext_via_traces = 1 if /AM_GNU_GETTEXT/;
$uses_libtool = 1 if /AC_PROG_LIBTOOL/;
@@ -468,6 +471,24 @@
if $uses_gettext_via_traces && ! $uses_gettext;
error "$configure_ac: AM_GNU_GETTEXT_VERSION is used, but not AM_GNU_GETTEXT"
if $uses_gettext && ! $uses_gettext_via_traces;
+
+
+ # #
+ # Setting up the source tree. #
+ # #
+
+ # libtoolize, automake --add-missing etc. will drop files in the
+ # $AUX_DIR. But these tools fail to install these files if the
+ # directory itself does not exist, which valid: just imagine a CVS
+ # repository with hand written code only (there is not even a need
+ # for a Makefile.am!).
+
+ if (defined $aux_dir && ! -d $aux_dir)
+{
+ verb "$configure_ac: creating directory $aux_dir";
+ mkdir $aux_dir
+ or error "cannot create $aux_dir: $!";
+}
# #
Index: lib/autom4te.in
===
RCS file: /cvsroot/autoconf/autoconf/lib/autom4te.in,v
retrieving revision 1.20
diff -u -u -r1.20 autom4te.in
--- lib/autom4te.in 19 Aug 2003 07:58:37 - 1.20
+++ lib/autom4te.in 3 Oct 2003 07:28:59 -
@@ -61,6 +61,7 @@
## -- ##
begin-language: "Autoreconf-preselections"
+args: --preselect AC_CONFIG_AUX_DIR
args: --preselect AC_CONFIG_HEADERS
args: --preselect AC_CONFIG_SUBDIRS
args: --preselect AC_INIT
Re: GNU Automake 1.7.9 released
>>> "Chuck" == Charles Wilson <[EMAIL PROTECTED]> writes:
Chuck> What is this "Autoconf 2.59" of which you speak? I saw this
Chuck> http://mail.gnu.org/archive/html/autoconf-patches/2003-11/msg00010.html
Chuck> But there does not yet appear to be a tarball available.
> I'm using the AUTOCONF-2_59 tag from CVS. I didn't know it
> hasn't been announced yet. All I can say is that Akim is away
> today and tomorrow, so you'll have to wait if you want an
> official tarball.
I have a problem on my machine that prevents me from finishing the
releasing process :(
/tmp % cat foo.c nostromo 9:16
int
main ()
{
return 42;
}
/tmp % gcc foo.c nostromo 9:49
/usr/bin/ld: cannot open crt1.o: No such file or directory
collect2: ld returned 1 exit status
When I have some time, I fix this, and finish the release :(
Re: Current versions of automake and autoconf
> Anyway, back to Dalibor's question: > 2.57 is the last version announced to [EMAIL PROTECTED] > 2.58 is the last version available on ftp.gnu.org > 2.59 is the last version (pre-)announced to [EMAIL PROTECTED] > Which one is to be considered the last official release? I > understand it's not 2.59; and you disgraced 2.58 in another > mail. Next Automake needs at least 2.58, but if this is not an > official release we have to wait. I'd like to see 2.59 uploaded asap. Consider they are all official releases now. But I meant to avoid advertising 2.58 too much since it has flaws that make it troublesome with Automake 1.8, while 2.59 is OK. But the release process at GNU has changed again, and I'm stuck with my tarballs on my site. I don't have enough time to learn yet another uploading scheme, and I don't know whether Paul could make progress. Other than that, 2.59 was released. I'm just waiting for ftp.gnu.org before sending the announcement to all the list, especially info-gnu.
Re: RFE: Restricting a package to a particular automake version
> Hi, > With the release of automake-1.8 ahead, a request for enhancement: > automake-1.8 probably will be incompatible to automake-1.7 > Up to now I have encountered 2 incompatiblities: > * The generating info files in $srcdir issue. > * aclocal complaining about underquoting in custom macros. You can't call this an incompatibility! It is only a warning, and a very good warning: pacifying it means being on the safe side whatever the version of Autoconf and/or Automake.
Re: RFE: Restricting a package to a particular automake version
> When having several dozens of configure.ac's in source tree and even
> more custom aclocal macros, causing 100's of warnings, you may relate
> why I don't share your opinion.
perl -pi.bak -e 's/(AC_DEFUN\()(\w+\),/$1[$2],g' **/*.{ac,m4}
should make it!
Re: automake and i18n
> Hi, > beginning with version 0.13, GNU gettext has full support for Perl > scripts, with libintl-perl (http://search.cpan.org/dist/libintl-perl/) > there is a stable runtime environment for gettext like message > translation in Perl, and with yours truly there is somebody available > that would volunteer to make the necessary modifications for > internationalizing automake. > It is possible to do the internationalization in such a way, that > automake would still run without libintl-perl being installed. > License problems should not be an issue, libintl-perl is distributed > under the LGPL. As for the required Perl version, Perl 5.004 is > sufficient for libintl-perl. > Comments? Do you know any maintainer that does not know English? In other words, what's the use? Will you translate the documentation too?
Re: automake and i18n
> Hi, > Akim Demaille wrote: >> > It is possible to do the internationalization in such a way, that >> > automake would still run without libintl-perl being installed. >> > License problems should not be an issue, libintl-perl is distributed >> > under the LGPL. As for the required Perl version, Perl 5.004 is >> > sufficient for libintl-perl. >> > Comments? >> Do you know any maintainer that does not know English? In other >> words, what's the use? Will you translate the documentation too? > Why are other GNU developer packages like "make" or "gcc" > internationalized? Because they are already heavily documented elsewhere. The two precise examples you chose are GNU versions of world wide spread utilities. But I hear your point, I just beg to differ on the relative importance. And I'm waiting for requests to internationalize configure, and the messages embedded in the Makefile rules :)
Re: Current versions of automake and autoconf
> (Answering only for Automake, because I've also been confused by > Akim's last statements about announcements that shouldn't be > considered official.) Sorry about this. I was trying to make a difference bw pre-released on my web site, and really released on GNU site. Maybe that was wrong :( It turns out that a beta, even if you emphasize the need to test it, is not tested as thoroughly as a real release. So I was finally quite happy with having a (pre-)release spread in our community first, then have some real feedback before making the real release. This caught a couple of weak releases by the past, but I realize that this releasing scheme is a bit obscure. Unfortunately it relied on this obscurity: it is important, if you want some real feedback, that many people use it as a real release. So if I flag it as a pre-release, I doubt it will be tested as thoroughly :( In the future I'll try to be clearer. And I'm open to suggestions on how to improve the feedback on Autoconf :)
Re: about requiring Perl 5.6 in Automake 1.9
> I'm considering dropping support for Perl 5.005 in the future > Automake 1.9, and require at least Perl 5.6. Perl 5.6 will be 4 > years old next month, so it does not sound like asking for the > moon. Actually, why not jumping to something really more recent. Some people will have to upgrade their Perl installation, so they probably won't install 5.6 anyway. Sarathy 5.6.1-TRIAL1 2000-Dec-18 The 5.6 maintenance track. 5.6.1-TRIAL2 2001-Jan-31 5.6.1-TRIAL3 2001-Mar-19 5.6.1-foolish 2001-Apr-01 The "fools-gold" release. 5.6.1 2001-Apr-08 Rafael 5.6.2-RC1 2003-Nov-08 5.6.2 2003-Nov-15 Fix new build issues Jarkko 5.7.0 2000-Sep-02 The 5.7 track: Development. 5.7.1 2001-Apr-09 5.7.2 2001-Jul-13 Virtual release candidate 0. 5.7.3 2002-Mar-05 5.8.0-RC1 2002-Jun-01 5.8.0-RC2 2002-Jun-21 5.8.0-RC3 2002-Jul-13 5.8.0 2002-Jul-18 5.8.1-RC1 2003-Jul-10 5.8.1-RC2 2003-Jul-11 5.8.1-RC3 2003-Jul-30 5.8.1-RC4 2003-Aug-01 5.8.1-RC5 2003-Sep-22 5.8.1 2003-Sep-25 Nicholas 5.8.2-RC1 2003-Oct-27 5.8.2-RC2 2003-Nov-03 5.8.2 2003-Nov-05 5.8.3-RC1 2004-Jan-07 5.8.3 2004-Jan-14 Hugo 5.9.0 2003-Oct-27 How about 5.8? What's the version shipped with current RedHats etc.?
Re: RFC: doc for `Handling Tools that Produce Many Outputs'
> Personally, I positively *like* "witness" - it describes what it is > in a colourful way. For the records, this is the official English word for the same concept in logic. A witness of an existential quantifier \exists x. P(x) is precisely a t such that P(t). So I believe witness is perfect for the current job. I remember we had a similar debate for Autoconf years ago. I can't remember the point though. Any witness?
Python & Automake
Hi!
I'm looking for the recommended way to handle Python executables.
I've read the current documentation, but it refers only to Python
libraries (unless I'm mistaken).
Looking for some inspiration, I found this old piece of code from
François Pinard, but it's problem completely outdated.
AUTOMAKE_OPTIONS = gnits
bin_SCRIPTS = libitize
pkgdata_DATA = libit.pyc
EXTRA_DIST = libitize.in libit.py
PYTHON = @PYTHON@
SUFFIXES = .py .pyc
.py.pyc:
@echo "Compiling $<..."
@$(PYTHON) -c "import py_compile; py_compile.compile('$<', '$*.pyc')"
[EMAIL PROTECTED]@
# Update a distribution by using libit files.
# Copyright © 2000 Progiciels Bourbeau-Pinard inc.
# François Pinard <[EMAIL PROTECTED]>, 2000.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
import string, sys
sys.path.insert(0, '@prefix@/share/@PACKAGE@')
package = '@PACKAGE@'
version = '@VERSION@'
prefix = '@prefix@'
datadir = string.replace('@datadir@', '${prefix}', prefix)
pkgdatadir = string.replace('@pkgdatadir@', '${datadir}', datadir)
import libit
apply(libit.main, tuple(sys.argv[1:]))
Aside from the needed update for the Makefile.am machinery, is the top
level generation and redirection the recommended way?
Automatic source filename computation
The fact that Automake infers some source file names from check_PROGRAMS = test-foo is really nice. Nevertheless, it is nice to people who program in C, and less to other languages. Couldn't we look for test-foo.EXT with EXT ranging a well defined series instead of the hard coded `c'? I know it's a bit of magic, and it could be compared to globbing support. I find it weaker though, so more admissible. An alternative would be a DEFAULT_EXTENSION variable, that's more controlled.
Texi2Text
[Sorry for the delays, I have suffered sysadmin issues.] 1BGDpl-0001aY-Fa-D Are there any plans of texi->text support? The recent very welcome addition of pdf and html targets seem to call for other outputs: plain text, XML and so forth.
.texi.html: Add a touch?
makeinfo does not update timestamps of directories:
% ls -dltr maintain.{texi,html} nostromo 15:12
drwxr-xr-x2 akim lrde 4096 2004-05-25 14:38 maintain.html/
-rw-r--r--1 akim lrde16132 2004-05-25 15:01 maintain.texi
% LC_ALL=C /bin/sh /home/akim/lectures/maintain/config/missing --run makeinfo --html
--enable-encoding --number-sections --fill-column=76 -I . \
> -o maintain.html maintain.texi
% ls -dltr maintain.{texi,html}
drwxr-xr-x2 akim lrde 4096 2004-05-25 14:38 maintain.html/
-rw-r--r--1 akim lrde16132 2004-05-25 15:01 maintain.texi
which keeps this rule unsatisfied:
.texi.html:
$(MAKEINFOHTML) $(AM_MAKEINFOHTMLFLAGS) $(MAKEINFOFLAGS) -I $(srcdir) \
-o $@ $<
if test ! -d $@ && test -d $(@:.html=); then \
mv $(@:.html=) $@; else :; fi
This can cause bad problems when trying to install under a different
identity:
% sudo -u doc make install nostromo 15:06
LC_ALL=C /bin/sh /home/akim/lectures/maintain/config/missing --run makeinfo --html
--enable-encoding --number-sections --fill-column=76 -I . \
-o maintain.html maintain.texi
/home/akim/lectures/maintain/maintain.html/index.html: Permission denied
make: *** [maintain.html] Erreur 1
so I suggest the following change:
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* lib/am/texibuild.am (.texi.html): Touch the output to update its
timestamp, which is not performed by makeinfo when producing a
directory.
Index: lib/am/texibuild.am
===
RCS file: /cvs/automake/automake/lib/am/texibuild.am,v
retrieving revision 1.21
diff -u -u -r1.21 texibuild.am
--- lib/am/texibuild.am 15 May 2004 16:12:07 - 1.21
+++ lib/am/texibuild.am 25 May 2004 13:21:50 -
@@ -87,6 +87,8 @@
## instead of foo.html/).
if test ! -d $@ && test -d $(@:.html=); then \
mv $(@:.html=) $@; else :; fi
+## makeinfo does not update the timestamp of the directory.
+ touch $@
## If we are using the generic rules, we need separate dependencies.
## (Don't wonder about %DIRSTAMP% here, this is used only by non-generic
Installing split Texinfo HTML files
Hi! What is the recommended way to install split HTML documentation from Texinfo? It would be nice if Automake had the bit of magic to copy directories, instead of simple files, in this precise. In addition, there is a small catch when the user does it by herself: I had the following in my Makefile.am: install-data-local: cp -r $(HTMLS) $(DESTDIR)$(htmldir) And unfortunately this -local target is triggered before Automake's code, which results in: ~/lectures/maintain % sudo -u doc make install nostromo 14:46 make[1]: entrant dans le répertoire « /home/akim/lectures/maintain » make[1]: Rien à faire pour « install-exec-am ». cp -r maintain.html /mnt/dload/maintain test -z "/mnt/dload/maintain" || mkdir -p -- . "/mnt/dload/maintain" ... in other words, the directory is created after I meant to use it. And thanks to the changing semantics of cp, I obtained the content in ../maintain instead of ../maintain/maintain.html :) Thanks in advance!
Re: .texi.html: Add a touch?
>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: > makeinfo does not update timestamps of directories: Is there a problem with this patch?
Re: .texi.html: Add a touch?
>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: >>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: >> makeinfo does not update timestamps of directories: > Is there a problem with this patch? Ping!
Re: Mac OSX vs. VPATH vs. Automake's auto disted files
Le 23 août 04, à 18:58, Paul D. Smith a écrit : %% Akim Demaille <[EMAIL PROTECTED]> writes: ad> I met a problem on Mac OSX, and diagnosed it as follows. I would not ad> call this a problem in Automake. Probably GNU Make 3.79 is the most ad> likely culprit, but at least I wanted to describe this issue in case ad> someone else finds it. ad> The problem is that ad> - Mac OSX (by default) is case preserving, but case insensitive ad> - Make, when looking for dependencies correctly understands this This is not true. Unless you are setting some special flags in the build of GNU make (please let me know what they are if so) GNU make always assumes normal UNIX filesystem semantics: that is, case-sensitive and case-preserving. Any means to get the flags from make itself? I don't know how Apple built it: that's stock Make. What is probably happening here is that make is looking up the filename and the underlying operating system sees that it does exist (because it's case-insensitive). But make does not understand this. ad> - but Make no longer understands this properly when meeting ad> dependencies requires walking the VPATH and when the case is ad> not exactly the same. In this case what's probably happening is that VPATH is causing make to read the directory structure into its directory cache, and then make is looking through the list of files in the directory and doing string comparisons to find the filename. In this case, of course, the strings will not match so the VPATH lookup fails. OK. There is a #define in the GNU make code called HAVE_CASE_INSENSITIVE_FS which you can set if your filesystem is case-insensitive. Set it in config.h after the configure script has run; that might help. If so we can think about whether this is something that should always be set for OSX. I'm not sure about the "always". It is my understanding that not all the FS on MacOSX are case insensitive.
nodist_info_TEXINFOS
How is one expected to request to ship some Texinfo files, but not the info files, as these are to be built? I found nothing in the documentation, and a naive nodist_info_TEXINFOS = assignments.texi tiger.texi does not ship the texi files (of course...). And this, naive also, approach does not solve the problem. EXTRA_TEXINFOS = $(nodist_info_TEXINFOS)
Shipping generated file from generated generator
Suppose you have a file generated-output that's built from feeding generator with input. generator itself is built from generator.sources. I would like to ship generated-output (hence it's in srcdir), to spare the user the need to build it. I don't know how to do that without using .SECONDARY, which doesn't appear to be universal amongst makes. Is there a more portable solution? Here is a test case, under the form of a... test case :) interm.test Description: Binary data It fails without the .SECONDARY.
Re: Shipping generated file from generated generator
>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes: > Hello Akim, Hi! > -- > noinst_PROGRAMS = makedoc > bin_PROGRAMS = ginfo infokey > makedoc_SOURCES = makedoc.c > ginfo_SOURCES = echo-area.c echo-area.h ... \ > doc.c funs.h > infokey_SOURCES = infokey.c infokey.h key.c key.h funs.h > generated_sources = doc.c key.c funs.h > $(generated_sources): makedoc$(EXEEXT) $(cmd_sources) > rm -f $(generated_sources) > $(top_builddir)/$(native_tools)/info/makedoc $(cmd_sources) Warning: Read the node `Multiple Outputs' in Automake.texi. > cmd_sources = $(srcdir)/session.c $(srcdir)/echo-area.c $(srcdir)/infodoc.c \ > $(srcdir)/m-x.c $(srcdir)/indices.c $(srcdir)/nodemenu.c \ > $(srcdir)/footnotes.c $(srcdir)/variables.c > # The following hack is necessary to hint make before the automatic > # dependencies are built. See the automake manual for a detailed explanation. > BUILT_SOURCES = funs.h > -- Do this work? The sources are never re-generated on the user side? I don't see the difference with my case actually, but for me, it builds the generator and rebuilds the generated-output. Also, I see no provision to generate these files in srcdir. Are you really sure you ship and use them?
Re: Shipping generated file from generated generator
Hm, reading more carefully, I see no connection between the generated_sources and what they are used to. I would say your Makefile is missing dependencies, that's why it 'works'. But an update of one of the cmd_sourcs will probably not update the whole set, as it should.
Re: Shipping generated file from generated generator
>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes: > I guess the following should fix it: > $(generated_sources): $(makedoc_SOURCES) $(cmd_sources) > make $(AM_MAKEFLAGS) makedoc$(EXEEXT) $(MAKE) > rm -f $(generated_sources) > ./makedoc $(cmd_sources) > This way the generated_sources shouldn't be regenerated, if they are new > enough. >> Hm, reading more carefully, I see no connection between the >> generated_sources and what they are used to. > The dependency of the wole program on eg. key.c is done by the automake > variable infokey_SOURCES. Ah, I was looking for generated_sources itself, not its contents. >> Also, I see no provision to generate these files in srcdir. Are you >> really sure you ship and use them? > I guess ``make dist'' was always called in the main tree, so this > was not a problem. [*] Nope, it was: distcheck always does a src != build configuration. Unless distcheck was never used (booh :).
Re: Shipping generated file from generated generator
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: >>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: > [...] Akim> I don't know how to do that without using .SECONDARY, Akim> which doesn't appear to be universal amongst makes. Is Akim> there a more portable solution? > I don't know of any, and I recommend against it. A distributed > file should never depend upon a non-distributed built file (see > also node distcleancheck in the FAQ). This limitation is a problem in our case, since our build time is already way too long for the typical user, so we do want to pre-build as much as possible. In addition, the files I am referring to (those that are generated) are demo-files (that also serve as test cases). It is weird for demo-files not to be in srcdir. But the suggested workaround (running $(MAKE)) is probably just what we need. Thanks!
Re: Error because README is missing
>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes: > Untested code ahead. > m4_syscmd([test -f build.sh.in])dnl > m4_if(m4_sysval, 0, [AC_CONFIG_FILES(build.sh)]) Bad idea: side effects are incompatible with the (autom4te) cache. If the environment changes but not the sources of configure, it won't be regenerated. Similarly with what Automake needs to trace.
Re: Error because README is missing
>>> "Paul" == Paul Smith <[EMAIL PROTECTED]> writes: > %% Akim Demaille <[EMAIL PROTECTED]> writes: >>>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes: >>> Untested code ahead. >>> m4_syscmd([test -f build.sh.in])dnl >>> m4_if(m4_sysval, 0, [AC_CONFIG_FILES(build.sh)]) ad> Bad idea: side effects are incompatible with the (autom4te) cache. ad> If the environment changes but not the sources of configure, it ad> won't be regenerated. Similarly with what Automake needs to ad> trace. > OK :-(. > I need a way to have a file marked as a config file, but not have > configure (or automake) fail if the .in input file doesn't exist. > How can I do this? Hm... What is the service you are expecting? You say that configure shouldn't fail, but if it's a config file, configure is expected to fail. Unless you do mean configure, and not config.status?
dist_TESTS
I'd like that!
Re: Error because README is missing
>>> "Paul" == Paul Smith <[EMAIL PROTECTED]> writes: > %% Akim Demaille <[EMAIL PROTECTED]> writes: >>> I need a way to have a file marked as a config file, but not have >>> configure (or automake) fail if the .in input file doesn't exist. ad> Hm... What is the service you are expecting? You say that ad> configure shouldn't fail, but if it's a config file, configure is ad> expected to fail. Unless you do mean configure, and not ad> config.status? > When I first check out my code from CVS, I don't have a build.sh.in > file. That file is autogenerated as part of the build process, from a > template file. If you have a bootstrap script, why wouldn't it create a fake file, run autoreconf, and them create the right file? Do you run autoreconf several times? It seems so, since that's what implied Andreas' solution. Finally, note that you are allowed to ask config.status to perform substitutions on files it doesn't know[1]. In your case, I'm unsure binding the instantiation to configure instead of make is right. An example: in autoconf's tree. src/ace/_build % ./config.status --help nostromo 17:45 `config.status' instantiates files from templates according to the current configuration. Usage: ./config.status [OPTIONS] [FILE]... -h, --help print this help, then exit -V, --versionprint version number, then exit -q, --quiet do not print progress messages -d, --debug don't remove temporary files --recheckupdate config.status by reconfiguring in the same conditions --file=FILE[:TEMPLATE] instantiate the configuration file FILE Configuration files: config/Makefile tests/Makefile tests/atlocal tests/autoconf:tests/wrapper.in tests/autoheader:tests/wrapper.in tests/autom4te:tests/wrapper.in tests/autoreconf:tests/wrapper.in tests/autoscan:tests/wrapper.in tests/autoupdate:tests/wrapper.in tests/ifnames:tests/wrapper.in man/Makefile lib/emacs/Makefile Makefile doc/Makefile lib/Makefile lib/Autom4te/Makefile lib/autoscan/Makefile lib/m4sugar/Makefile lib/autoconf/Makefile lib/autotest/Makefile bin/Makefile Configuration commands: tests/atconfig Report bugs to <[EMAIL PROTECTED]>. src/ace/_build % echo "@srcdir@" > foo.innostromo 17:45 src/ace/_build % ./config.status --file=foo nostromo 17:45 config.status: creating foo src/ace/_build % cat foo nostromo 17:45 ..
filename-length-max=99
Why isn't it enabled when using tar-v7?
AM_LDFLAGS vs. maude_la_LDFLAGS
It is my understanding (after having re-read the doc ;) that these flags are exclusive: either one of the two is used. So I have in a Makefile.am of mine: | AM_LDFLAGS = -avoid-version -module -shared | ... | # Override AM_LDFLAGS: this guy must not be a module. | libtcswigpy_la_LDFLAGS = and Makefile.in does contain: libtcswigpy.la: $(libtcswigpy_la_OBJECTS) $(libtcswigpy_la_DEPENDENCIES) $(CXXLINK) -rpath $(pyexecdir) $(libtcswigpy_la_LDFLAGS) $(libtcswigpy_la_OBJECTS) $(libtcswigpy_la_LIBADD) $(LIBS) but CXXLINKS is: CXXLINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ --mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) $(AM_LDFLAGS) \ $(LDFLAGS) -o $@ so I'm stuck with AM_LDFLAGS although I meant to escape from it. Of course I'll get rid of AM_LDFLAGS, but I'm not sure I was an outlaw according to the documentation. And shouldn't the LDFLAGS be last? It is in CXXLINKS, but in the command line.
Re: AM_LDFLAGS vs. maude_la_LDFLAGS
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: > Whether using libtcswigpy_la_LDFLAGS in addition to AM_LDFLAGS is > an error I don't know. It is not nice: (i) it is a different semantics than the other variables, and (ii) the more common semantics is more flexible. > OTOH, the current behavior of AM_LDFLAGS vs. maude_LDFLAGS > sounds very counterintuitive to me. Even if it breaks some > package, I'd rather fix this to match the handling of the other > flag variables than document and carry over this exception. 100% agreed. Nice patch, many thanks!
Re: texi2dvi: A more pleasant way to compile
>>> "Karl" == Karl Berry <[EMAIL PROTECTED]> writes: [The thread starts in http://lists.gnu.org/archive/html/bug-texinfo/2005-05/msg00019.html] > finding the xref files is much easier, > That's a good point. Finding all those aux files has always been a drag. > Still wanna keep the old scheme? > I'm not sure yet. > So the new work is merely to add *.t2d in .cvsignore (or whatever), and > CLEANFILES = *.t2d in Makefile.am, until Automake is updated? Anything > else? Yes: CLEANFILES is for files only. So it's either # Heek. CLEANFILES = -rf *.t2d or clean-local: rm -rf *.t2d
Re: texi2dvi: A more pleasant way to compile
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: >>> "Karl" == Karl Berry <[EMAIL PROTECTED]> writes: >>> So the new work is merely to add *.t2d in .cvsignore (or whatever), and >>> CLEANFILES = *.t2d in Makefile.am, until Automake is updated? > Can we work on an interface that will not require any change in > Automake the next time texi2dvi invents new files or > directories? That's the whole point: now there is no reason for additional files/directories to be created. > Having an operation mode where texi2dvi cleans itself the > auxiliary files that it would otherwise create sounds right to > me. In other words, I'd like `make mostlyclean' to call > `texi2dvi --mostlyclean input.texi' for all `input.texi', > instead of having to know how texi2dvi works internally. > (I think that's an old idea from Akim.) That's right :) But that's already too late for older texi2dvi, so I think you will most probably never use this feature in Automake (just as you will most probably not get rid of the silly list of hard coded extensions that Texinfo files might create) Sure, you can affort to -texi2dvi --mostlyclean rm -rf ... but is there really any point? I'm fine with implementing this, I'm merely asking whether it will be used.
Re: texi2dvi: A more pleasant way to compile
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: Akim> is there really any point? > It's simple to implement and it's cleaner to use. It also shows a > good example of an interface we would both like to see in many > other tools. Of course you're right. Thanks for keeping me away from the dark side.
Re: AC_PROG_CC
> "Johan" == Johan Rydberg <[EMAIL PROTECTED]> writes: Johan> ... It says that I should run autoupdate (which I have done) to Johan> corrent this, but nothing happens. autoupdate doesn't update Johan> the specified line. What is the exact message? Though this line may have triggered the message, it might be something deeper, used by this macro. Then it might be an m4/*.m4 that needs to be updated. BTW, this is probably an Autoconf only problem, hence [EMAIL PROTECTED] is more appropriate. Akim
Re: Single line dependency lists become too long
> "Merijn" == Merijn de Jonge <[EMAIL PROTECTED]> writes: Merijn> This line is too long for configure to instantiate and the Merijn> result is a truncated line of dependencies. What happens? Do you know where this limitation comes from? Akim
Re: Additional aclocal dir
> "Assar" == Assar Westerlund <[EMAIL PROTECTED]> writes: Assar> "Gabor Z. Papp" <[EMAIL PROTECTED]> writes: >> can I use/define somehow additional aclocal directory, where I can >> put additional m4 files? Assar> Yes, use `aclocal -I dir' where dir is the directory of your Assar> additional files. If you want that to get included in your Assar> Makefile.in, you can do something like: Assar> ACLOCAL = @ACLOCAL@ -I dir Or ACLOCAL_AMFLAGS = -I dir which is slighly better, since I don't think autoreconf will recognize the former, while it definitely knows the latter. Akim
Re: libtool /tmp security
| On Mar 13, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
| > I would still like to see {auto{conf,make},libtool} use Ralf
| > Engelschall's shtool (or a variant of it) to encapsulate the
| > portability issues of things like mkdir -p and mkdir -m 700 into a
| > single script rather than scattered across the sources...
Absolutely. Missing and alike should be moved from Automake to
Autoconf actually, and the ability that Automake and Libtool plug new
modules is fundamental too.
As for mkdir -m, it seems to me that
(umask 700 && mkdir /tmp/foo)
is just fine.
| Yup. Something like this has been suggested for automake's
| `missing', and I'm thinking about the best way to make it work.
|
| I've just tought we could keep it in an initial section of
| `configure'. Then, we'd arrange for `autoconf' to preserve that
| section, and we'd need some tool to add/remove/update shtools within
| that special section of configure. Comments?
This idea has been raised several times, and it is big work. We have
to choose a solution, and spread it in the *tools. Now, it seems to
me that yet we are totally unable to target a release, which I sorely
regret. Adding that new pressure to Autoconf 2.15 is not something
I'm willing to do.
Let's close Automake 1.5, Autoconf 2.15 and Libtool 1.4 some day,
which means, let's avoid big changes. We have to converge some day.
I'm dying for the day Automake will use Autoconf's new feature, and
since it is apparently not the next release, super-missing and other
shtools should be delayed till then.
Akim
Re: Additional aclocal dir
>>>>> "Assar" == Assar Westerlund <[EMAIL PROTECTED]> writes: Assar> Akim Demaille <[EMAIL PROTECTED]> writes: >> ACLOCAL_AMFLAGS = -I dir >> >> which is slighly better, since I don't think autoreconf will >> recognize the former, while it definitely knows the latter. Assar> Yes, but autoreconf 2.13 does not understand that. :-( Ooops, sorry :(
Re: libtool /tmp security
>>>>> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes: Earnie> --- Akim Demaille <[EMAIL PROTECTED]> wrote: -8<- >> As for mkdir -m, it seems to me that >> >> (umask 700 && mkdir /tmp/foo) Grmph, 077. >> >> is just fine. >> Earnie> -8<- Earnie> Why use /tmp at all? Since autoconf is for portibility you Earnie> can't really assume that /tmp exists. Why not simply create a Earnie> temporary directory in the current working directory? IMO Earnie> this would handle any security issues as well as any race Earnie> issues. Let it be for speed issues, I'm in favor of /tmp via TMPDIR. This should be portable enough, and testing it beforehand is OK. Now, if experts consider this is a security hole...
Re: libtool /tmp security
> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes: >> Let it be for speed issues, I'm in favor of /tmp via TMPDIR. This Earnie> You missed the point; /tmp isn't portable, it doesn't always Earnie> exist (E.G.: MSDOS or WINDOWS). At least with TMPDIR I can Earnie> set it to be whatever I want it to be. That's precisely what I meant, and Alexandre also demonstrated it is required for Libtool. Earnie> If you want speed do mkdir ./foo instead of mkdir -m /tmp/foo. Nope, I'm talking about possibly mounted src dirs, while /tmp is local, so faster. Akim
Re: m4/missing.m4 in CVS
| On Feb 2, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: | >>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: | Alexandre> Only CVS autoconf accepts implicitly quotes backticks in | Alexandre> MSGs. But it complains if backtick is already quoted. | Alexandre> Relying upon the autoconf-CVS behavior is a mistake, IMO, | Alexandre> and the fact that autoconf complains (warns) about quoted | Alexandre> backticks is also a mistake, IMO. I'd rather revert to the | Alexandre> explicitly quoted backtick in automake, and arrange that | Alexandre> autoconf doesn't complain about the quoted backtick. Akim? | Alexandre> Tom? OK with that, but in the future, it should be reactivated. | > My opinion is that we implicitly supported the idea that using CVS | > Automake *is* using CVS Autoconf and conversely. | | Not if it can be helped. CVS autoconf requires a whole lot of changes | in `configure.in's to keep it quiet, and automake is still usable | without any of these features. I'm totally against coupling releases | of software unless it can't be helped. Which means that I'd really | like if automake CVS could still be used without autoconf CVS, even | after it is improved to make use of --trace and such. Yes, this means | keeping backward-compatibility code. Which, IMO, is a good thing. The whole point of --trace is to remove the internal knowledge Automake has of Autoconf. I consider this as a flaw serious enough so that we require a simultaneous update here. We are not breaking compatibility. Yes, there are warnings, but warnings still belong to the same world, the code needs no change. Have a look at the current Autoconf: it uses AC_PROG_GNU_M4 which Automake doesn't know, so Automake does not give the template for @M4@, we have to give it by hand. This is bad, very bad. Because of the former design, Automake had to do this. It should no longer do that. If you want to maintain compatibility, then I see no point in moving to --trace. Actually, you still require that the users update their Automake when moving to Autoconf 2.15, precisely because there are many constructs that are not supported by 1.4. As I already detailed in many threads, I really think we should release Automake 1.5 and Autoconf 2.15 so that we no longer have to do that. I might be over optimistic, but to me autoconf --trace is revolutionizing the relationship between the two. We must make the big jump, because for the design point of view, we considerably ease our task, *and* the users are provided with a much more robust framework. | I have enough trouble convincing other developers of other projects, | such as Kaffe, to use libtool and automake from CVS, because they | offer features we really need. I'd rather not force them to install | and use autoconf CVS too. People walking on the wild CVS tracks should be ready to move to the three amigos at the same time. I know this is not good, I know this perfectly well, but IMHO we face a major revamping of the whole system, and we ought to make it right, not polluted because of comfort for this or that particular person. The separation between Autoconf's and Automake's responsibilities is a major improvement over the previous scheme. There should not remain any molten cheese threads between the Automake pizza part, and the Autoconf pizza part. Let's cut frankly, and end with the Automake's nightmare which tries to palliate the Autoconf flows. We're doing free software. There is no warranty whatsoever that the maintainers will complicate their tasks and compromising their future just for a little additional comfort. And again, I shall emphasize that this little comfort is a myth: you *need* to update Automake if you update Autoconf, let it be because Automake still doesn't support AC_CONFIG_FILES, AC_CONFIG_HEADERS and the like, new AC_SUBST variables etc. | > So, though I'm not frankly against having this silent, I'm not in | > favor of it. | | This problem has just cost me a whole hour of investigation, trying to | figure out what the heck was wrong with AC_PROG_LN_S, which was where | bash reported the error to be (after the matching backtick). I even | suspected someone had hacked into the lab and replaced bash with some | non-working shell! I don't understand what you mean. This issue has be commented several times, and in addition the guilty message is given explicitly in the warning. I agree though that the location of the warnings are usually not very pertinent. Akim
Re: m4/missing.m4 in CVS
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> On Mar 13, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: >> And again, I shall emphasize that this little comfort is a myth: >> you *need* to update Automake if you update Autoconf, let it be >> because Automake still doesn't support AC_CONFIG_FILES, >> AC_CONFIG_HEADERS and the like, new AC_SUBST variables etc. Alexandre> But I'm not talking about updating autoconf, that's the Alexandre> whole point. I just wanted to update automake, and, Alexandre> because of a minor patch that fixed one minor inconvenience Alexandre> (an autoconf warning), I wasted a whole hour investigating Alexandre> a problem that seemed to be totally unrelated. I agree, but as I said, I'm really hoping that we will soon move the --trace, so it is just trying to sneak in before the door is really closed. Alexandre> Whenever automake decides it's time to adopt the new Alexandre> autoconf's features, I won't be able to update automake Alexandre> without updating autoconf too. Before that, I'd rather not Alexandre> fall into this trap again. I hope we start this this week or the next, but we should not wait longer. >> I don't understand what you mean. This issue has be commented >> several times, and in addition the guilty message is given >> explicitly in the warning. Alexandre> I was using autoconf 2.13, and automake's missing.m4 Alexandre> contained: Alexandre> AC_MSG_WARN([`missing'...]) Alexandre> Note, the backtick was not quoted. The quote had been Alexandre> removed to silence CVS autoconf. Aaah, didn't understand, sorry. Yep, this kind of trap is painful. zsh -x does a good job here. And I really thought that Automake had not changed its missing.m4. Automake should AC_PREREQ(2.14a). Alexandre> he'll get weird error messages from [s]hell! :-) :) :)
Re: m4/missing.m4 in CVS
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> I'd really prefer to have a stable release of automake with Alexandre> the many the new features introduced since release 1.4, Alexandre> particularly user-side dependency tracking, before starting Alexandre> to rely on CVS autoconf features. It means Autoconf still has a long way before being released. We can't release Autoconf without support from Automake. I know I'm going to ask the kind of question maintainers don't like to hear, so don't flame me, I'll just handle this by myself... You guy, first you finish your duties, release the final version of your manuscript, catch up your back log, and *then* you may ask such embarrassing questions in public. Clean up before your door first (or, alternatively, throw the first stone to yourself). So... (sorry, I have to...), do we have any time frame for Automake? What needs to be done in Automake so that it is releasable? Akim
Re: Why does Makefile depend on BUILT_SOURCES?
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> Grant Akim write access and we'll quickly get all of Alexandre> automake revamped :-) :) Alexandre> Akim, no offense intended :-) None taken :) Akim
Re: flex -lfl
> "Sascha" == Sascha Ziemann <[EMAIL PROTECTED]> writes: Sascha> One needs -lfl and the other not. Just don't use -lfl at all. It contains a dummy main, which you certainly already have available somewhere else, and a dummy yywrap, which you can write: return 1. Alternatively, use %option noyywrap. And then the flex file is self contained. Akim
Re: flex -lfl
> "Sascha" == Sascha Ziemann <[EMAIL PROTECTED]> writes: Sascha> - How can I check for flex and bison instead of lex and yacc? Sascha> I use some flex/bison specific features, which would not work Sascha> with lex/yacc. Here's what I do: # I want flex, and only flex AM_PROG_LEX if test "$LEX" = lex; then LEX="$missing_dir/missing flex" LEX_OUTPUT_ROOT=lex.yy AC_SUBST(LEX_OUTPUT_ROOT)dnl fi So that even if $LEX=lex, I don't run it. Akim
Re: the appropriate location for depcomp
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Tom> So, I'm planning to change the rule to always choose top_srcdir Tom> as the default location (i.e., in the final step). Comments? If you mean for *all* the files, I'm all for it. Amongst the various choices, the best one is most probably the one which needs the smallest amount of documentation, hence everything in top_srcdir. Akim
Re: Absolute srcdir
I'm on something comparable in Autoconf. Don't know if it's the same, but I'll keep you informed. Akim
Re: Absolute srcdir
Ralf Corsepius sent me this morning a detailed PR with about the same behavior. I'm highly tempted to consider this a bash bug, unless someone can demonstrate the usefulness of the following feature... /tmp/build % cat /tmp/foo.sh nostromo 19:22 #! /bin/sh case "/foo" in [/\\]*) echo 1;; esac case "/foo" in /* | \\*) echo 2;; esac case "/foo" in [\\/]*) echo 3;; esac case "\foo" in [/\\]*) echo 1;; esac case "\foo" in /* | \\*) echo 2;; esac case "\foo" in [\\/]*) echo 3;; esac /tmp/build % bash /tmp/foo.shnostromo 19:24 2 3 1 2 3 /tmp/build % zsh /tmp/foo.sh nostromo 19:24 1 2 3 1 2 3 I suppose we should drop the use of [] here. Pfff.
Re: Absolute srcdir
| Alexandre Oliva wrote: | > On Mar 27, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: | > | > > I'm highly tempted to consider this a bash bug | > | > So am I. Which `bash' is that? I've just tested 2.04, and it *does* | > present the bug :-( | | # bash --version | GNU bash, version 2.03.0(1)-release (i686-pc-linux-gnu) | Copyright 1998 Free Software Foundation, Inc. ~tig % bash --versionnostromo 10:35 GNU bash, version 2.04.0(1)-beta5 (i386-pc-linux-gnu) Copyright 1999 Free Software Foundation, Inc.
Re: Absolute srcdir
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
Ralf> What about this fragment from acgeneral.m4 (~line 4407):
Ralf> [[/\\$]]* | ?:[[/\\]]*) INSTALL="$ac_given_INSTALL" ;;
Ralf> There, [[/\\$]]* is used instead of [[/\\]]*.
For variables which can contain ${prefix} and such.
| ~tig % cat /tmp/foo.sh
| #! /bin/sh
|
| case "/foo" in
| [$/\\]*) echo 1;;
| esac
|
| case "/foo" in
| [\\/]*) echo 2;;
| esac
|
| case "\foo" in
| [/\\$]*) echo 3;;
| esac
|
| case "\foo" in
| [\\/$]*) echo 4;;
| esac
~tig % bash /tmp/foo.sh
2
3
4
~tig % zsh /tmp/foo.sh
1
2
3
4
Seems like we should use `[\\/]' and `[\\/$]'.
Ralf> Seems like another workaround to this issue already crept into
Ralf> autoconf to me.
Parse error :) The `to me' matches `Seems, or `creep'?
Akim
Re: automake --build-dir
>>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> CVS Autoconf sticks to Automake 1.4: that's why you find all Akim> those problems. Use 1.4 instead, that's the easier way out. Oops, now I remember you *should* use 1.4, otherwise, because we rely on something which has changed between 1.4 and CVS (\-line breaking), your tests/macros.m4 file will probably be bizarre. Any fix welcome :) Also, note that the test suite still needs to be taught the compiler to use, it uses cc by default. We are slowly catching up with this problem, but it's a bit delicate to fix it. IMHO when facing AC_INIT AC_CHECK_HEADERS(stdio.h) Autoconf should AC_REQUIRE AC_PROG_COMPILER, AC_PROG_COMPILER being dependent of the current language. Some machinery was added to make it less impossible (remember? imposible is not French, although impossible is :). Akim
Re: automake --build-dir
> "Erez" == Erez Zadok <[EMAIL PROTECTED]> writes: >> > Update: I managed to solve that problem by rerunning automake on >> the .am > files in the autoconf CVS repository. >> >> You must re-run aclocal before automake. Erez> Thanks. Erez> I still, however, seem to have a problem with make dist creating Erez> files in one place and looking for them in another. Have you Erez> tried to make dist in a a build dir that's not srcdir? Is it Erez> working for you when you start from a clean just-checked-out Erez> repository? CVS Autoconf sticks to Automake 1.4: that's why you find all those problems. Use 1.4 instead, that's the easier way out. Akim
Re: automake --build-dir
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> On Apr 2, 2000, Erez Zadok <[EMAIL PROTECTED]> wrote: >> Have you tried to make dist in a a build dir that's not srcdir? Alexandre> A long time ago, I installed a patch in autoconf to make it Alexandre> work. I don't know if it has been broken again since then. Maybe I don't know. I never practiced this :(. >> Is it working for you when you start from a clean just-checked-out >> repository? Alexandre> Nope. The first problem is that autoconf needs itself to Alexandre> bootstrap. Not really, the CVS repository contains the full tarball (with configure, Makefile.in etc.). Alexandre> The second problem is that its aclocal.m4 must not be Alexandre> updated with automake; instead, you must manually update Alexandre> the various m4 files within the m4 directory. I'm not sure Alexandre> I like this setup. I want Autoconf to be the first to use what it advocates, but we sure can roll back to using the beloved aclocal :). Alexandre> The other problem is that, since automake no longer sees Alexandre> the AC_SUBSTs in m4/*.m4, it won't automatically define Alexandre> them in the top-level Makefile.in. That's why AMTAR is not Alexandre> defined at all :-( Not only that, it won't see the new AC_SUBST which are in the library files, such as M4, from AC_PROG_GNU_M4 :( So you have to install the @M4@ yourself. But this one is already added by hand. Akim
[Harlan Stenn ] Re: obsolete AC_OUTPUT_COMMANDS in AM_CONFIG_HEADER
This patch is still lacking in the current Automake.
Akim
This patch seems to work for me to solve the problem of splitting the
original AC_OUTPUT(...) into AC_CONFIG_FILES(...) and AC_OUTPUT.
It applies just as easily to automake.in .
--- /usr/local/gnu/bin/automake Mon Dec 20 00:09:39 1999
+++ automakeSun Jan 23 17:19:31 2000
@@ -4397,6 +4397,12 @@
$in_ac_output = 1;
$ac_output_line = $.;
}
+ # Process the AC_CONFIG_FILES macro.
+ if (! $in_ac_output && s/AC_CONFIG_FILES\s*\(\[?//)
+ {
+ $in_ac_output = 1;
+ $ac_output_line = $.;
+ }
if ($in_ac_output)
{
local ($closing) = 0;
patch: AC_CONFIG_HEADERS
This simple patch just changes
- if (/A([CM])_CONFIG_HEADER\s*\((.*)\)/
+ if (/A([CM])_CONFIG_HEADERS?\s*\((.*)\)/
but there are some trailing spaces which were killed too by
whitespace.el.
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* automake.in (scan_one_configure_file): Recognize also
AC_CONFIG_HEADERS.
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.782
diff -u -r1.782 automake.in
--- automake.in 2000/04/05 20:55:48 1.782
+++ automake.in 2000/04/13 10:14:26
@@ -957,7 +957,7 @@
# dependency tracking was requested, and this extension
# supports it, then we don't generate the rule here.
local ($comp) = '';
-
+
if ($use_dependencies && $language_map{$lang . '-autodep'} ne 'no')
{
# Don't generate the rule, but still generate the variables.
@@ -1250,7 +1250,7 @@
# Compute the rule to compile this object.
local ($flag) = $language_map{$lang . '-flags'};
local ($val) = "(${derived}_${flag}";
- ($rule = $language_map{$lang . '-compile'}) =~
+ ($rule = $language_map{$lang . '-compile'}) =~
s/\(AM_$flag/$val/;
$rule .= ' ' . $language_map{$lang . '-output-arg'};
@@ -1996,7 +1996,7 @@
# Check that the library fits the standard naming convention.
$libname_rx = "^lib.*\.la";
if (&variable_value ($xlib . '_LDFLAGS') =~ /-module/
- || &variable_value ('LDFLAGS') =~ /-module/)
+ || &variable_value ('LDFLAGS') =~ /-module/)
{
# Relax name checking for libtool modules.
$libname_rx = "\.la";
@@ -2725,7 +2725,7 @@
# thing. If we're in the topmost directory, then we use
# `distdir' instead of `top_distdir'; this lets us work
# correctly with an enclosing package.
- $output_rules .=
+ $output_rules .=
("\t" . 'for subdir in $(' . $dist_subdir_name . '); do ' . "\\\n"
. "\t" . ' if test "$$subdir" = .; then :; else ' . "\\\n"
. "\t" . 'test -d $(distdir)/$$subdir ' . "\\\n"
@@ -2969,7 +2969,7 @@
local ($flag) = $language_map{$lang . '-flags'};
local ($val) = "(${derived}_${flag}";
- ($rule = $language_map{$lang . '-compile'}) =~
+ ($rule = $language_map{$lang . '-compile'}) =~
s/\(AM_$flag/$val/;
$rule =~ s,([/\$]),\\$1,g;
@@ -4502,7 +4502,7 @@
# Handle configuration headers. A config header of `[$1]'
# means we are actually scanning AM_CONFIG_HEADER from
# aclocal.m4.
- if (/A([CM])_CONFIG_HEADER\s*\((.*)\)/
+ if (/A([CM])_CONFIG_HEADERS?\s*\((.*)\)/
&& $2 ne '[$1]')
{
&am_conf_line_error
@@ -6266,7 +6266,7 @@
local ($source_suffix);
local ($object_suffix);
- if (($source_suffix, $object_suffix) = ($1 =~ $SUFFIX_RULE_PATTERN))
+ if (($source_suffix, $object_suffix) = ($1 =~ $SUFFIX_RULE_PATTERN))
{
$suffix_rules{$source_suffix} = $object_suffix;
print "Sources ending in .$source_suffix become .$object_suffix\n" if
$verbose;
Akim
Patch: init.m4
I've already sent this patch, but it has not been applied yet. Here is an updated version. Akim Index: ChangeLog from Akim Demaille <[EMAIL PROTECTED]> * m4/init.m4 (AC_PROVIDE_IFELSE): If it is not defined, do it. (AM_INIT_AUTOMAKE): Update the writing conventions. Quote properly the arguments. Add a few missing `dnl'. Use AC_PROVIDE_IFELSE. Index: m4/init.m4 === RCS file: /cvs/automake/automake/m4/init.m4,v retrieving revision 1.17 diff -u -r1.17 init.m4 --- init.m4 1999/11/23 05:08:42 1.17 +++ init.m4 2000/04/13 10:32:23 @@ -2,29 +2,46 @@ # some checks are only needed if your package does certain things. # But this isn't really a big deal. -# serial 1 +# serial 2 -dnl Usage: -dnl AM_INIT_AUTOMAKE(package,version, [no-define]) +# AC_PROVIDE_IFELSE(MACRO-NAME, IF-PROVIDED, IF-NOT-PROVIDED) +# --- +# If MACRO-NAME is provided do IF-PROVIDED, else IF-NOT-PROVIDED. +# The purpose of this macro is to provide the user with a means to +# check macros which are provided without letting her know how the +# information is coded. +# If this macro is not defined by Autoconf, define it here. +ifdef([AC_PROVIDE_IFELSE], + [], + [define([AC_PROVIDE_IFELSE], + [ifdef([AC_PROVIDE_$1], + [$2], [$3])])]) + +# AM_INIT_AUTOMAKE(PACKAGE,VERSION, [NO-DEFINE]) +# -- AC_DEFUN(AM_INIT_AUTOMAKE, -[AC_REQUIRE([AC_PROG_INSTALL]) -dnl We require 2.13 because we rely on SHELL being computed by configure. -AC_PREREQ([2.13]) -PACKAGE=[$1] -AC_SUBST(PACKAGE) -VERSION=[$2] -AC_SUBST(VERSION) -dnl test to see if srcdir already configured +[dnl We require 2.13 because we rely on SHELL being computed by configure. +AC_PREREQ([2.13])dnl +AC_REQUIRE([AC_PROG_INSTALL])dnl +# test to see if srcdir already configured if test "`CDPATH=: && cd $srcdir && pwd`" != "`pwd`" && test -f $srcdir/config.status; then AC_MSG_ERROR([source directory already configured; run "make distclean" there first]) fi + +# Define the identity of the package. +PACKAGE=$1 +AC_SUBST(PACKAGE)dnl +VERSION=$2 +AC_SUBST(VERSION)dnl ifelse([$3],, -AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE", [Name of package]) -AC_DEFINE_UNQUOTED(VERSION, "$VERSION", [Version number of package])) -AC_REQUIRE([AM_SANITY_CHECK]) -AC_REQUIRE([AC_ARG_PROGRAM]) +[AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE", [Name of package.]) +AC_DEFINE_UNQUOTED(VERSION, "$VERSION", [Version number of package.])]) + +# Some tools Automake needs. +AC_REQUIRE([AM_SANITY_CHECK])dnl +AC_REQUIRE([AC_ARG_PROGRAM])dnl AM_MISSING_PROG(ACLOCAL, aclocal) AM_MISSING_PROG(AUTOCONF, autoconf) AM_MISSING_PROG(AUTOMAKE, automake) @@ -34,12 +51,16 @@ AM_MISSING_INSTALL_SH dnl We need awk for the "check" target. The system "awk" is bad on dnl some platforms. -AC_REQUIRE([AC_PROG_AWK]) -AC_REQUIRE([AC_PROG_MAKE_SET]) -AC_REQUIRE([AM_DEP_TRACK]) -AC_REQUIRE([AM_SET_DEPDIR]) -ifdef([AC_PROVIDE_AC_PROG_CC], [AM_DEPENDENCIES(CC)], [ - define([AC_PROG_CC], defn([AC_PROG_CC])[AM_DEPENDENCIES(CC)])]) -ifdef([AC_PROVIDE_AC_PROG_CXX], [AM_DEPENDENCIES(CXX)], [ - define([AC_PROG_CXX], defn([AC_PROG_CXX])[AM_DEPENDENCIES(CXX)])]) +AC_REQUIRE([AC_PROG_AWK])dnl +AC_REQUIRE([AC_PROG_MAKE_SET])dnl +AC_REQUIRE([AM_DEP_TRACK])dnl +AC_REQUIRE([AM_SET_DEPDIR])dnl +AC_PROVIDE_IFELSE([AC_PROG_CC], + [AM_DEPENDENCIES(CC)], + [define([AC_PROG_CC], + defn([AC_PROG_CC])[AM_DEPENDENCIES(CC)])])dnl +AC_PROVIDE_IFELSE([AC_PROG_CXX], + [AM_DEPENDENCIES(CXX)], + [define([AC_PROG_CXX], + defn([AC_PROG_CXX])[AM_DEPENDENCIES(CXX)])])dnl ])
patch: compile
Already sent. Akim Index: ChangeLog from Akim Demaille <[EMAIL PROTECTED]> * compile: Simplify the use of double quotes in assignments. Index: compile === RCS file: /cvs/automake/automake/compile,v retrieving revision 1.1 diff -u -r1.1 compile --- compile 1999/04/11 13:02:41 1.1 +++ compile 2000/04/13 10:37:01 @@ -2,7 +2,7 @@ # Wrapper for compilers which do not understand `-c -o'. -# Copyright (C) 1999 Free Software Foundation, Inc. +# Copyright (C) 1999, 2000 Free Software Foundation, Inc. # Written by Tom Tromey <[EMAIL PROTECTED]>. # # This program is free software; you can redistribute it and/or modify @@ -23,7 +23,7 @@ # compile PROGRAM [ARGS]... # `-o FOO.o' is removed from the args passed to the actual compile. -prog="$1" +prog=$1 shift ofile= @@ -32,11 +32,11 @@ while test $# -gt 0; do case "$1" in -o) - ofile="$2" + ofile=$2 shift ;; *.c) - cfile="$1" + cfile=$1 args="$args $1" ;; *) @@ -57,10 +57,10 @@ } # Name of file we expect compiler to create. -cofile="`echo $cfile | sed -e 's|^.*/||' -e 's/\.c$/.o/'`" +cofile=`echo $cfile | sed -e 's|^.*/||' -e 's/\.c$/.o/'` # Create the lock directory. -lockdir="`echo $ofile | sed -e 's|/|_|g'`" +lockdir=`echo $ofile | sed -e 's|/|_|g'` while true; do if mkdir $lockdir > /dev/null 2>&1; then break
patch: .yy -> .hh
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
foo.yy should generate foo.cc and foo.hh, not foo.h.
* automake.in (output_yacc_build_rule): Don't pretend to use a
third argument.
Transform the generated header's suffix as you do for the
generated parser file.
(output_lex_build_rule): Register the `$c_suffix'.
* automake.texi (Yacc and Lex): Document.
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.782
diff -u -w -r1.782 automake.in
--- automake.in 2000/04/05 20:55:48 1.782
+++ automake.in 2000/04/20 14:06:52
@@ -1049,27 +1049,32 @@
# compiled with C or C++, depending on the extension of the YACC file.
sub output_yacc_build_rule
{
-local ($yacc_suffix, $use_ylwrap, $c_suffix) = @_;
+local ($yacc_suffix, $use_ylwrap) = @_;
-local ($suffix);
-($suffix = $yacc_suffix) =~ tr/y/c/;
-push (@suffixes, $yacc_suffix, $suffix);
+local ($c_suffix, $h_suffix);
+($c_suffix = $yacc_suffix) =~ tr/y/c/;
+($h_suffix = $yacc_suffix) =~ tr/y/h/;
+push (@suffixes, $yacc_suffix, $c_suffix, $h_suffix);
# Generate rule for c/c++.
-$output_rules .= "$yacc_suffix$suffix:\n\t";
+$output_rules .= "$yacc_suffix$c_suffix:\n\t";
if ($use_ylwrap)
{
$output_rules .= ('$(SHELL) $(YLWRAP)'
- . ' "$(YACC)" $< y.tab.c $*' . $suffix
- . ' y.tab.h $*.h -- $(AM_YFLAGS) $(YFLAGS)');
+ . ' "$(YACC)" $< y.tab.c $*' . $c_suffix
+ . ' y.tab.h $*.' . $h_suffix
+ . ' -- $(AM_YFLAGS) $(YFLAGS)');
}
else
{
$output_rules .= ('$(YACC) $(AM_YFLAGS) $(YFLAGS) $< && mv y.tab.c $*'
- . $suffix . "\n"
+ . $c_suffix . "\n"
. "\tif test -f y.tab.h; then \\\n"
- . "\tif cmp -s y.tab.h \$*.h; then rm -f y.tab.h; else mv
y.tab.h \$*.h; fi; \\\n"
+ . "\tif cmp -s y.tab.h \$*" . $h_suffix . " then "
+ . "rm -f y.tab.h; "
+ . "else "
+ . "mv y.tab.h \$*.". $h_suffix . "; fi; \\\n"
. "\telse :; fi");
}
$output_rules .= "\n";
@@ -1078,10 +1083,10 @@
sub output_lex_build_rule
{
local ($lex_suffix, $use_ylwrap) = @_;
-local ($c_suffix);
+local ($c_suffix);
($c_suffix = $lex_suffix) =~ tr/l/c/;
-push (@suffixes, $lex_suffix);
+push (@suffixes, $lex_suffix, $c_suffix);
&define_configure_variable ('LEX_OUTPUT_ROOT');
&define_configure_variable ('LEXLIB');
$output_rules .= "$lex_suffix$c_suffix:\n\t";
Index: automake.texi
===
RCS file: /cvs/automake/automake/automake.texi,v
retrieving revision 1.180
diff -u -w -r1.180 automake.texi
--- automake.texi 2000/03/23 05:15:47 1.180
+++ automake.texi 2000/04/20 14:08:39
@@ -52,7 +52,7 @@
@page
@vskip 0pt plus 1filll
-Copyright @copyright{} 1995, 96 Free Software Foundation, Inc.
+Copyright @copyright{} 1995, 96, 2000 Free Software Foundation, Inc.
@sp 2
This is the first edition of the GNU Automake documentation,@*
and is consistent with GNU Automake @value{VERSION}.@*
@@ -1792,7 +1792,8 @@
of the resulting @samp{C} or @samp{C++} file. Files with the extension
@samp{.y} will be turned into @samp{.c} files; likewise, @samp{.yy} will
become @samp{.cc}; @samp{.y++}, @samp{c++}; and @samp{.yxx},
-@samp{.cxx}.
+@samp{.cxx}. If headers are generated, the same transformation applies
+(@samp{.yy} will become @samp{.hh} etc.).
Likewise, lex source files can be used to generate @samp{C} or
@samp{C++}; the extensions @samp{.l}, @samp{.ll}, @samp{.l++}, and
@@ -1806,11 +1807,16 @@
included in any distribution that is made. That way the user doesn't
need to have @code{yacc} or @code{lex}.
+@vindex YFLAGS
+@vindex LFLAGS
+
If a @code{yacc} source file is seen, then your @file{configure.in} must
define the variable @samp{YACC}. This is most easily done by invoking
the macro @samp{AC_PROG_YACC} (@pxref{Particular Programs, , Particular
-Program Checks, autoconf, The Autoconf Manual}).
+Program Checks, autoconf, The Autoconf Manual}). You may use
+@samp{YFLAGS} to pass additional flags to @code{yacc}.
+
Similarly, if a @code{lex} source file is seen, then your
@file{configure.in} must define the variable @samp{LEX}. You can use
Re: Patch: init.m4
Maybe this patch could be rejected/discussed/applied? | Index: m4/init.m4 | === | RCS file: /cvs/automake/automake/m4/init.m4,v | retrieving revision 1.17 | diff -u -r1.17 init.m4 | --- init.m4 1999/11/23 05:08:42 1.17 | +++ init.m4 2000/04/13 10:32:23 | @@ -2,29 +2,46 @@ | # some checks are only needed if your package does certain things. | # But this isn't really a big deal. | | -# serial 1 | +# serial 2 | | -dnl Usage: | -dnl AM_INIT_AUTOMAKE(package,version, [no-define]) | +# AC_PROVIDE_IFELSE(MACRO-NAME, IF-PROVIDED, IF-NOT-PROVIDED) | +# --- | +# If MACRO-NAME is provided do IF-PROVIDED, else IF-NOT-PROVIDED. | +# The purpose of this macro is to provide the user with a means to | +# check macros which are provided without letting her know how the | +# information is coded. | +# If this macro is not defined by Autoconf, define it here. | +ifdef([AC_PROVIDE_IFELSE], | + [], | + [define([AC_PROVIDE_IFELSE], | + [ifdef([AC_PROVIDE_$1], | + [$2], [$3])])]) I did this in order to release Automake from the internals of Autoconf. | +# AM_INIT_AUTOMAKE(PACKAGE,VERSION, [NO-DEFINE]) | +# -- | AC_DEFUN(AM_INIT_AUTOMAKE, | -[AC_REQUIRE([AC_PROG_INSTALL]) | -dnl We require 2.13 because we rely on SHELL being computed by configure. | -AC_PREREQ([2.13]) | -PACKAGE=[$1] | -AC_SUBST(PACKAGE) | -VERSION=[$2] | -AC_SUBST(VERSION) | -dnl test to see if srcdir already configured | +[dnl We require 2.13 because we rely on SHELL being computed by configure. | +AC_PREREQ([2.13])dnl | +AC_REQUIRE([AC_PROG_INSTALL])dnl | +# test to see if srcdir already configured I did this because the usual style consists in putting at the top of the macro definition things which are requirements, and which don't expand anything. | if test "`CDPATH=: && cd $srcdir && pwd`" != "`pwd`" && | test -f $srcdir/config.status; then |AC_MSG_ERROR([source directory already configured; run "make distclean" there |first]) | fi | + | +# Define the identity of the package. | +PACKAGE=$1 | +AC_SUBST(PACKAGE)dnl | +VERSION=$2 | +AC_SUBST(VERSION)dnl I did this because above the AC_SUBST are not dnled, and also the variables were over quoted. | ifelse([$3],, | -AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE", [Name of package]) | -AC_DEFINE_UNQUOTED(VERSION, "$VERSION", [Version number of package])) | -AC_REQUIRE([AM_SANITY_CHECK]) | -AC_REQUIRE([AC_ARG_PROGRAM]) | +[AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE", [Name of package.]) | +AC_DEFINE_UNQUOTED(VERSION, "$VERSION", [Version number of package.])]) I did this because since the body of the ifelse was not quoted plenty of funny things could happen. Fortunately AC_DEFINE macros are rather safe, but... | +# Some tools Automake needs. | +AC_REQUIRE([AM_SANITY_CHECK])dnl | +AC_REQUIRE([AC_ARG_PROGRAM])dnl | AM_MISSING_PROG(ACLOCAL, aclocal) | AM_MISSING_PROG(AUTOCONF, autoconf) | AM_MISSING_PROG(AUTOMAKE, automake) | @@ -34,12 +51,16 @@ | AM_MISSING_INSTALL_SH | dnl We need awk for the "check" target. The system "awk" is bad on | dnl some platforms. | -AC_REQUIRE([AC_PROG_AWK]) | -AC_REQUIRE([AC_PROG_MAKE_SET]) | -AC_REQUIRE([AM_DEP_TRACK]) | -AC_REQUIRE([AM_SET_DEPDIR]) | -ifdef([AC_PROVIDE_AC_PROG_CC], [AM_DEPENDENCIES(CC)], [ | - define([AC_PROG_CC], defn([AC_PROG_CC])[AM_DEPENDENCIES(CC)])]) | -ifdef([AC_PROVIDE_AC_PROG_CXX], [AM_DEPENDENCIES(CXX)], [ | - define([AC_PROG_CXX], defn([AC_PROG_CXX])[AM_DEPENDENCIES(CXX)])]) | +AC_REQUIRE([AC_PROG_AWK])dnl | +AC_REQUIRE([AC_PROG_MAKE_SET])dnl | +AC_REQUIRE([AM_DEP_TRACK])dnl | +AC_REQUIRE([AM_SET_DEPDIR])dnl | +AC_PROVIDE_IFELSE([AC_PROG_CC], | + [AM_DEPENDENCIES(CC)], | + [define([AC_PROG_CC], | + defn([AC_PROG_CC])[AM_DEPENDENCIES(CC)])])dnl | +AC_PROVIDE_IFELSE([AC_PROG_CXX], | + [AM_DEPENDENCIES(CXX)], | + [define([AC_PROG_CXX], | + defn([AC_PROG_CXX])[AM_DEPENDENCIES(CXX)])])dnl | ]) I did this to add the missing dnl and use AC_PROVIDE_IFELSE. Akim
Re: patch: .yy -> .hh
Sorry, I sent this mail by accident before I had commented it. Automake has some support for Lex and Yacc files intended for C++, based on .yy, .y++ or even yxx. It generates the corresponding .cc, .c++ and .cxx, but does not apply the same transformation to headers. There is also a couple of typos I think, I'm not sure: | -local ($yacc_suffix, $use_ylwrap, $c_suffix) = @_; | +local ($yacc_suffix, $use_ylwrap) = @_; There is only one call to this function, and with two args, not three. Also, c_suffix was not used. In order to be consistent with the lex-handling function, I used c_suffix, not suffix. Anyway, it is nicer if you introduce h_suffix. | -push (@suffixes, $yacc_suffix, $suffix); Based on this in the Yacc code, I concluded that the lex code needed to do the same, hence | -push (@suffixes, $lex_suffix); | +push (@suffixes, $lex_suffix, $c_suffix); I have put those two variables in the v index, as some other variables, but I'm not sure to understand the first two indexes: @c Define an index of configure output variables. @defcodeindex ov @c Define an index of configure variables. @defcodeindex cv There are no uses of ov, and cv contains a lot of macro names: ~/src/automake % fgrep ovindex automake.texi nostromo 16:52 ~/src/automake % fgrep cvindex automake.texi nostromo Err 1 @cvindex PACKAGE @cvindex AM_INIT_AUTOMAKE @cvindex AC_OUTPUT @cvindex AC_CONFIG_HEADER @cvindex AC_CONFIG_AUX_DIR @cvindex AC_PATH_XTRA @cvindex AC_CANONICAL_HOST @cvindex AC_CHECK_TOOL @cvindex AC_CANONICAL_SYSTEM @cvindex AC_FUNC_ALLOCA etc. Akim
Re: patch: .yy -> .hh
Hm, in fact I did the previous patch because Automake 1.4 created dependencies for .yy.hh, not for .yy.h, so it was wrong somewhere. Since I use .hh when I use .cc, it seemed logical to me that it was the .h which was wrong. But I sent the patch for CVS Automake, and I just discovered that it the other half is already changed: now Automake generates dependencies for .yy.h. 1999-03-26 Tom Tromey <[EMAIL PROTECTED]> * automake.in (lang_yacc_finish): Always use `.h' as suffix for yacc header file. From Ralf Corsepius. I suppose it is now a matter of religion to decide whether if .yy -> .cc then .yy -> .hh. Akim
Re: patch: .yy -> .hh
>>>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Akim> I suppose it is now a matter of religion
Tom> Yeah, basically.
OK, so I've extracted the atheist part of my patch, maybe it's useful?
Akim
Index: ChangeLog
===
RCS file: /cvs/automake/automake/ChangeLog,v
retrieving revision 1.864
diff -u -r1.864 ChangeLog
--- ChangeLog 2000/04/15 09:13:49 1.864
+++ ChangeLog 2000/04/21 08:28:50
@@ -1,3 +1,10 @@
+2000-04-21 Akim Demaille <[EMAIL PROTECTED]>
+
+ * automake.in (output_yacc_build_rule, output_lex_build_rule): Be
+ more alike.
+ * automake.texi (Yacc and Lex): Give details on the Yacc generated
+ headers, and on YFLAGS and LFLAGS.
+
2000-04-13 Akim Demaille <[EMAIL PROTECTED]>
* compile: Remove unnecessary double quotes in assignments.
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.783
diff -u -r1.783 automake.in
--- automake.in 2000/04/15 08:30:14 1.783
+++ automake.in 2000/04/21 08:31:56
@@ -1049,25 +1049,25 @@
# compiled with C or C++, depending on the extension of the YACC file.
sub output_yacc_build_rule
{
-local ($yacc_suffix, $use_ylwrap, $c_suffix) = @_;
+local ($yacc_suffix, $use_ylwrap) = @_;
+local ($c_suffix);
-local ($suffix);
-($suffix = $yacc_suffix) =~ tr/y/c/;
-push (@suffixes, $yacc_suffix, $suffix);
+($c_suffix = $yacc_suffix) =~ tr/y/c/;
+push (@suffixes, $yacc_suffix, $c_suffix);
# Generate rule for c/c++.
-$output_rules .= "$yacc_suffix$suffix:\n\t";
+$output_rules .= "$yacc_suffix$c_suffix:\n\t";
if ($use_ylwrap)
{
$output_rules .= ('$(SHELL) $(YLWRAP)'
- . ' "$(YACC)" $< y.tab.c $*' . $suffix
+ . ' "$(YACC)" $< y.tab.c $*' . $c_suffix
. ' y.tab.h $*.h -- $(AM_YFLAGS) $(YFLAGS)');
}
else
{
$output_rules .= ('$(YACC) $(AM_YFLAGS) $(YFLAGS) $< && mv y.tab.c $*'
- . $suffix . "\n"
+ . $c_suffix . "\n"
. "\tif test -f y.tab.h; then \\\n"
. "\tif cmp -s y.tab.h \$*.h; then rm -f y.tab.h; else mv
y.tab.h \$*.h; fi; \\\n"
. "\telse :; fi");
@@ -1081,7 +1081,7 @@
local ($c_suffix);
($c_suffix = $lex_suffix) =~ tr/l/c/;
-push (@suffixes, $lex_suffix);
+push (@suffixes, $lex_suffix, $c_suffix);
&define_configure_variable ('LEX_OUTPUT_ROOT');
&define_configure_variable ('LEXLIB');
$output_rules .= "$lex_suffix$c_suffix:\n\t";
Index: automake.texi
===
RCS file: /cvs/automake/automake/automake.texi,v
retrieving revision 1.180
diff -u -r1.180 automake.texi
--- automake.texi 2000/03/23 05:15:47 1.180
+++ automake.texi 2000/04/21 08:32:11
@@ -52,7 +52,7 @@
@page
@vskip 0pt plus 1filll
-Copyright @copyright{} 1995, 96 Free Software Foundation, Inc.
+Copyright @copyright{} 1995, 96, 2000 Free Software Foundation, Inc.
@sp 2
This is the first edition of the GNU Automake documentation,@*
and is consistent with GNU Automake @value{VERSION}.@*
@@ -131,8 +131,8 @@
* Extending:: Extending Automake
* Distributing::Distributing the Makefile.in
* Future:: Some ideas for the future
-* Macro and Variable Index::
-* General Index::
+* Macro and Variable Index::
+* General Index::
@end menu
@end ifinfo
@@ -680,7 +680,7 @@
@example
bin_PROGRAMS = hello
-hello_SOURCES = hello.c version.c getopt.c getopt1.c getopt.h system.h
+hello_SOURCES = hello.c version.c getopt.c getopt1.c getopt.h system.h
hello_LDADD = @@INTLLIBS@@ @@ALLOCA@@
localedir = $(datadir)/locale
INCLUDES = -I../intl -DLOCALEDIR=\"$(localedir)\"
@@ -1452,10 +1452,10 @@
* A Shared Library::Building a Libtool library
* Program variables:: Variables used when building a program
* Yacc and Lex::Yacc and Lex support
-* C++ Support::
-* Fortran 77 Support::
+* C++ Support::
+* Fortran 77 Support::
* Java Support::
-* Support for Other Languages::
+* Support for Other Languages::
* ANSI::Automatic de-ANSI-fication
* Dependencies::Automatic dependency tracking
@end menu
@@ -1488,7 +1488,7 @@
into an executable:
@example
-hello_SOURCES = hello.c version.c getopt.c getopt1.c getopt.h system.h
+hello_SOURCES = hello.c version.c getopt.c getopt1.c
Re: [Harlan Stenn ] Re: obsolete AC_OUTPUT_COMMANDS in AM_CONFIG_HEADER
In response to Didier in another thread, I don't think this patch was
applied.
Akim
| Akim Demaille <[EMAIL PROTECTED]> writes:
| | This patch is still lacking in the current Automake.
| |
| | Akim
|
| Thanks.
| I'll commit this instead:
|
| --- automake.in.~3~ Sat Apr 15 10:29:27 2000
| +++ automake.in Sat Apr 15 12:52:42 2000
| @@ -4402,8 +4402,8 @@ sub scan_one_configure_file
| &am_conf_line_error ($filename, $., "\`$1' is obsolete$hint");
| }
|
| - # Process the AC_OUTPUT macro.
| - if (! $in_ac_output && s/AC_OUTPUT\s*\(\[?//)
| + # Process the AC_OUTPUT and AC_CONFIG_FILES macros.
| + if (! $in_ac_output && s/AC_(OUTPUT|CONFIG_FILES)\s*\(\[?//)
| {
| $in_ac_output = 1;
| $ac_output_line = $.;
|
| | From: Harlan Stenn <[EMAIL PROTECTED]>
| | Subject: Re: obsolete AC_OUTPUT_COMMANDS in AM_CONFIG_HEADER
| | To: Akim Demaille <[EMAIL PROTECTED]>
| | cc: Erez Zadok <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED]
| | Date: Tue, 08 Feb 2000 20:44:52 -0500
| |
| | This patch seems to work for me to solve the problem of splitting the
| | original AC_OUTPUT(...) into AC_CONFIG_FILES(...) and AC_OUTPUT.
| |
| | It applies just as easily to automake.in .
| |
| | --- /usr/local/gnu/bin/automake Mon Dec 20 00:09:39 1999
| | +++ automakeSun Jan 23 17:19:31 2000
| | @@ -4397,6 +4397,12 @@
| | $in_ac_output = 1;
| | $ac_output_line = $.;
| | }
| | + # Process the AC_CONFIG_FILES macro.
| | + if (! $in_ac_output && s/AC_CONFIG_FILES\s*\(\[?//)
| | + {
| | + $in_ac_output = 1;
| | + $ac_output_line = $.;
| | + }
| | if ($in_ac_output)
| | {
| | local ($closing) = 0;
| |
| |
| | --
|
