Re: Portable moc/uic support - works for me
Hello, Alexandre! Thank you for quick reply! On Fri, 2006-02-03 at 08:01 +0100, Alexandre Duret-Lutz wrote: > >>> "PR" == Pavel Roskin <[EMAIL PROTECTED]> writes: > PR> - How portable is $(<:.h=.ui) in the suffix rules? > > I think this should work. Automake uses things like $(@:.info=) > in some of its rule already. In the meantime, I have discovered $*, which doesn't look so hairy. > But why not rename this rule ".ui.uic.cc:" and use "$<"? My assumption was that quux.h is required when quux.uic.cc is generated. As it turns out, uic simply uses the header name to create an #include statement. This simplifies things, since there is no need to add an additional dependency, which is tricky with suffix rules. > Unlike GNU Make, some Make implementations (e.g. Sun's) do not > know how to chain implicit rules. OK, that rule becomes .ui.uic.cc: $(QT_UIC) -o $@ -impl $*.h $< I won't repost Makefile.am now. For those who find this message looking to make moc/uic work with Automake, the reference implementation should be in the qgit sources. -- Regards, Pavel Roskin
Portable moc/uic support - works for me
Hello! I see many people here ask how to integrate Qt designer support, but nobody reported success. I could do it for a project called qgit (Qt frontend to git, the version control system used by the Linux kernel). I was able to test the project on FreeBSD with the native BSD make, and there were no errors concerning the makefiles. Here's the src/Makefile.am from qgit with the actual sources replaced with short placeholders and without irrelevant extra targets: -- bin_PROGRAMS = foo DISTSOURCES = foo.cpp DISTHEADERS_MOC = bar.h DISTHEADERS_NO_MOC = baz.h FORMS = quux.ui FORMHEADERS = $(FORMS:.ui=.h) MOC_CC = $(FORMS:.ui=.moc.cc) $(DISTHEADERS_MOC:.h=.moc.cc) UIC_CC = $(FORMS:.ui=.uic.cc) BUILT_SOURCES = $(FORMHEADERS) $(UIC_CC) $(MOC_CC) CLEANFILES = $(BUILT_SOURCES) EXTRA_DIST = $(FORMS) foo_SOURCES = $(DISTSOURCES) $(DISTHEADERS_MOC) $(DISTHEADERS_NO_MOC) nodist_foo_SOURCES = $(MOC_CC) $(UIC_CC) .ui.h: $(QT_UIC) -o $@ $< .h.moc.cc: $(QT_MOC) -o $@ $< .h.uic.cc: $(QT_UIC) -o $@ -impl $< $(srcdir)/$(<:.h=.ui) SUFFIXES = .h .ui .moc.cc .uic.cc -- As you can see, I'm using double extensions so that syntax rules can be used both for generating and for compiling generated sources. It's probably not necessary to use *.cpp for real sources and *.cc for generated ones, but it's convenient to distinguish them. While I want to share my positive experience, I'd like to hear from the Automake gurus if I'm doing something potentially problematic, in particular: - How portable are double extensions? (I'm more concerned about UNIX make issues than about MS DOS) - How portable is $(<:.h=.ui) in the suffix rules? - How safe are substitution references like $(FORMS:.ui=.h) in Automake variables? Does Automake calculate them (I guess it does, but keeps the original line in Makefile.in)? I actually tried another approach without double extensions. Real sources end with .cpp, sources generated by uic end with .cc and sources generated by moc end with .cxx (I chose standard extensions so that I won't need to force-feed them to the compiler as C++ sources). *.cc is compiled to libuic.a with a dummy per-target flag. *.cxx is compiled to libmoc.a with another dummy per-target flag. They are linked with the objects made from the real sources. It worked too, but Makefile was very large because it had rules for every file. -- Regards, Pavel Roskin
Re: Automake 1.7h uploaded (fourth beta for Automake 1.8)
On Tue, 2 Dec 2003, Alexandre Duret-Lutz wrote: > Hi people, > > Due to two last minute new features, we have yet another weekly beta > of Automake 1.8. I sincerely hope this is the last one. If you are > not blas?, or if you have not had the occasion to test previous > versions, please give this one a try. GNU Midnight Commander is OK, just tested it. One little nitpick. Either the message about underquoted macros in aclocal should cause aclocal to fail, or there should be a word "WARNING" in the message. I actually mistook this message for the reason why autogen.sh failed (the reason was unrelated to Automake). I mean this code in aclocal.in: print STDERR "$file:$.: underquoted definition of $2\n"; print STDERR "$file:$.: run info '(automake)Extending aclocal'\n" . "or see http://sources.redhat.com/automake/"; . "automake.html#Extending%20aclocal\n" By the way, wouldn't the "warn" function in Perl more appropriate? It's used elsewhere in aclocal.in. It doesn't add "WARNING" though. I also hope 1.8 will be released soon. I cannot wait for m4_include support. Many thanks to the Automake team. -- Regards, Pavel Roskin
Re: proposal to fork the build-tools projects
Hello, Tom! > The maintainers have to struggle to write portable shell code; they have > to constantly avoid the temptation to introduce new tool dependencies in > the wrong place; they can't even rely on GNU Make. Maybe I'm missing something, but portable code is easier to maintain. It's a simpler programming language. If somebody heavily uses GNU Make features, I would have to learn them to fix the makefile. Workarounds for bugs is a separate issue. The shell code written in configure.in is directly exposed to every buggy shell out there. Not every programmer is supposed to know all bugs in all subshells, and this should not disqualify him or her from contributing fixes to the configuration tools of a particular project (I mean little niche programs, like gtkyahoo, not Autoconf itself). This problem is not so acute in Automake - it writes the rules for you, and in most cases you don't need your own rules. With Autoconf, you often need to implement processing of user options. For example, there are two libraries, A and B, and only one can be used. There are at least (not counting --with-A=/path/to/A) 2 possibilities for each library (present and absent) and 3 possibilities for each option, (--with-A, -without-A, no option), which makes 36 combinations. There are no ready macros to implement user-friendly logic, i.e. printing something like "you don't want to use A, but I cannot find B". If you are going to make a fork, add a well-behaving shell to the requirements and leave out everything else. I know a project with configure script longer than 500k. Uncompressed sources of ash with function support are smaller than that. -- Regards, Pavel Roskin
Re: CVS automake v. nearly-1.6.4
Hello, Harlan! > Is there anything in the CVS repo that will not be part of the next automake > release? Old revisions, obviously :-) > IE, what do I want to use if I want to get the release candidate? Try "cvs log" on some file that is present is all releases, for example AUTHORS. There is no 1.7 branch there, so presumably the head branch will become the 1.7 release. If version 1.6.4 will be released, it will be released from the branch called "branch-1-6". -- Regards, Pavel Roskin
Re: Bootstrap script for CVS Automake
> Pavel> Bootstrapping Automake from CVS is quite hard now, so > Pavel> this script would be useful. Please put it on CVS. No > Pavel> need to include it into distributions. > > If you have the time, please go ahead and commit it along with a > mention in HACKING. Done. The new section in HACKING is called "Working with CVS". Please have a look if you want to add something to this topic. -- Regards, Pavel Roskin
Re: Bug in "distcheck" target?
Hello! It has occured to me that the complex "distcheck" procedure doesn't have to be integrated into Automake. In fact, "make distcheck" works with the tarball and treats it as a black box. Automake knows a lot about most of the files and can generate rules that work with those files. But the whole idea of "make distcheck" it to make sure that the whole package behaves properly, including the custom rules not generated by Automake. I believe that a separate program for testing packages would be a much more flexible solution. You would be able to get a package from the net and check if that package behaves good, i.e. that it doesn't try to run autoconf or automake, respects DESTDIR and prefix, has all standard targets, passes "make check" and so on. You could use a new distcheck script on old packages. You would not have to run automake on it, and you would test the package as is, not what it would become after upgrading to the latest and greatest automake. The script could even produce a report about properties of the package (i.e. whether prefix and DESTDIR affect all files, passed make targets, failed make targets etc). I'm not saying that "make distcheck" support should be dropped from Automake any time soon, but having a standalone script would reduce the need in making "make distcheck" more and more complex, and especially the need in introducing any new Automake options affecting strictness of "make distcheck". At some point, "make distcheck" would simply call "make dist" and run the standalone "distcheck" script with predefined DISTCHECK_FLAGS. -- Regards, Pavel Roskin
Fix for random failures in warnopts.test
Hello! warnopts.test fails randomly for me. I have just applied this patch that fixes the problem: * tests/warnopts.test: Fix random failures by removing Autoconf cache directory when configure.in changes. Use the code and the comment from tests/asm.test. --- tests/warnopts.test +++ tests/warnopts.test @@ -61,6 +61,14 @@ # Only two lines of warnings. test `wc -l < stderr` = 2 +# On fast machines the autom4te.cache created during the above run of +# $AUTOMAKE is likely to have the same time stamp as the configure.in +# created below; thus causing traces for the old configure.in to be +# used. We could do `sleep 2', but it's faster to erase the +# directory. (Erase autom4te*.cache, not autom4te.cache, because some +# bogus installations of Autoconf use a versioned cache.) +rm -rf autom4te*.cache + # If we add a global -Wnone, all warnings should disappear. cat >configure.in <
Re: This conditional test fails in 1.6d
Hello, Alexandre! > Pavel> Well, my package doesn't. Here's the test (full test > Pavel> with copyright is attached): > > Thanks a lot! I'm installing the following fix. The fix works. GNU Midnight Commander works with CVS Automake now. Thank you! -- Regards, Pavel Roskin
Re: Bootstrap script for CVS Automake
> The attached script may seem gross, but it does its job - using just sed > and perl, it creates temporary aclocal and automake, which recreate > aclocal.m4 and Makefile.in in all directories, and the later are exactly > the same as those currently on CVS. I'm sorry, that was a preliminary version. This one actually works on a clean CVS checkout. -- Regards, Pavel Roskin bootstrap.gz Description: GNU Zip compressed data
Bootstrap script for CVS Automake
Hello! The attached script may seem gross, but it does its job - using just sed and perl, it creates temporary aclocal and automake, which recreate aclocal.m4 and Makefile.in in all directories, and the later are exactly the same as those currently on CVS. Bootstrapping Automake from CVS is quite hard now, so this script would be useful. Please put it on CVS. No need to include it into distributions. Once this script works for everyone who uses Automake CVS, aclocal.m4 and Makefile.in can be removed from CVS. But this step is optional. I won't object if this script is renamed to autogen.sh or cvscompile or whatever. -- Regards, Pavel Roskin bootstrap.gz Description: GNU Zip compressed data
This conditional test fails in 1.6d
Hello! > Please SHOUT LOUD if your package works with Automake 1.6.3 but > doesn't with 1.6d. Well, my package doesn't. Here's the test (full test with copyright is attached): cat >>configure.in << 'EOF' AM_CONDITIONAL([USE_FOO], [true]) AC_PROG_CC EOF cat >Makefile.am << 'EOF' if USE_FOO foo_PROGRAMS = foo endif foodir = $(libdir)/foo foo_SOURCES = foo.c EOF $ACLOCAL || exit 1 $AUTOMAKE || exit 1 === Running test ./cond25.test /usr/src/automake/tests/testSubDir Makefile.am:2: `foo_PROGRAMS' is used but `foodir' is undefined. Makefile.am:6: unused variable: `foo_SOURCES' FAIL: cond25.test Automake 1.6.3 passes this test. I'm using Autoconf 2.54, bash 2.05a, perl 5.6.1. -- Regards, Pavel Roskin cond25.test.gz Description: GNU Zip compressed data
Re: Bug in "distcheck" target?
Hello! > Roger> && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base install \ > Roger> && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base installcheck \ > Roger> && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base uninstall \ > > Unfortunately `make installcheck' isn't expected to run in a > DESTDIR installation as it might run programs which read files > using the real $prefix. Let's make an option (that would go to AUTOMAKE_OPTIONS) to enable relaxed check using DESTDIR. `make installcheck' would be skipped if this option is used. For example, reiserfsprogs installs binaries to /sbin, and they has a good reason for that. Using DESTDIR is the only way that reiserfsprogs passes `make distcheck'. It's still better than `make dist' for making real releases. -- Regards, Pavel Roskin
Re: Install failures are ignored
Hello, Akim and Tom! > Pavel> The problem happens quite often because install cannot > Pavel> overwrite running executable files and happily goes ahead and > Pavel> installs data files. I have been fooled by this two or three > Pavel> times. > > I can't reproduce it with ash. Could you write some documentation for > autoconf.texi? Thanks! Sorry, it took me a while to reply. The problem _is_ generic, not Cygwin specific. It's just that on Cygwin you are much more likely to be unable to replace one file, but not the others, in the same directory. The problem can been reproduced on Red Hat Linux 7.3 (bash 2.05a, GNU make 3.79.1, Autoconf 2.53, Automake 1.6.3). /usr/local/bin/mc is a directory with permissions 000. make tries to install a file with that name, ignores the failure and finishes "successfully": [proski@marabou src]$ make install make[1]: Entering directory `/usr/local/src/mc.v0/src' /bin/sh ../config/mkinstalldirs /usr/local/bin /usr/bin/install -c mc /usr/local/bin/mc /usr/bin/install: cannot stat `/usr/local/bin/mc/mc': Permission denied /usr/bin/install -c mcmfmt /usr/local/bin/mcmfmt make install-exec-hook make[2]: Entering directory `/usr/local/src/mc.v0/src' make install_mcview make[3]: Entering directory `/usr/local/src/mc.v0/src' cd /usr/local/bin/ && rm -f mcview && ln -s mc mcview make[3]: Leaving directory `/usr/local/src/mc.v0/src' make install_mcedit make[3]: Entering directory `/usr/local/src/mc.v0/src' cd /usr/local/bin/ && rm -f mcedit && ln -s mc mcedit make[3]: Leaving directory `/usr/local/src/mc.v0/src' make[2]: Leaving directory `/usr/local/src/mc.v0/src' /bin/sh ../config/mkinstalldirs /usr/local/lib/mc/bin /usr/bin/install -c cons.saver /usr/local/lib/mc/bin/cons.saver make[1]: Leaving directory `/usr/local/src/mc.v0/src' [proski@marabou src]$ I don't understand the reference to "set -e". Take this makefile: default: for i in 0 1; do \ echo testing $$i; \ test $$i = 1; \ done Run make on the same pure GNU/Linux system: [proski@marabou shell-test]$ make for i in 0 1; do \ echo testing $i; \ test $i = 1; \ done testing 0 testing 1 [proski@marabou shell-test]$ There's no error. Now add "set -e", so that the makefile is now: default: set -e; \ for i in 0 1; do \ echo testing $$i; \ test $$i = 1; \ done [proski@marabou shell-test]$ make set -e; \ for i in 0 1; do \ echo testing $i; \ test $i = 1; \ done testing 0 make: *** [default] Error 1 [proski@marabou shell-test]$ Feel the difference. Sorry, I don't know if I was supposed to try it on BSD. Two important results (sorry if they are obvious): 1) make (even GNU make) executes scripts without implicit "set -e" - it just executes separate commandes separately and checks the exit code of each of them. "set -e" is not in effect for the shell. make does its best to emulate "set -e", but doesn't split commands on the same line. 2) Explicit exit should be used inside separate commands (separate from the point of view of make) if errors may not affect the exit code of the whole command. By the way, what if the user runs "make -k"? An "exit" would terminate the loop, even though the user wants make to do as much as possible. This would be especially bad if the loop is for subdirectories - a failure in the first of them would cause all other subdirectories to be skipped, and only local commands outside the loop would be executed. You can consider this as a low-priority feature request for Automake. Perhaps it can be done by examining $(MAKE) for GNU make. -- Regards, Pavel Roskin
Re: spam
Hi! [Sorry for offtopic, but since Christoph wants to discuss this in the list, I don't want readers to see only his replies, but not mine] > proski> Install a spam filter. I use SpamAssassin. You can download it from > proski> http://spamassassin.org/ > > Not everybody has the possibility to install a filter (i am not the system > administrator) SpamAssassin can be installed with user permissions and used from procmail. Read the documentation. My configuration: fetchcmail gets mail and uses procmail as MDA (mail delivery agent). procmail sorts some mailing lists first - I don't want it to remove spam from the lists I administer, because this would hide my failures. It also passes e-mail from known people - if a spammer impersonates them or they get a virus, I want to know that. Then SpamAssassin checks for spam. The spam goes to a separate folder for review and reporting to spamcop.net. Then my (old, pre-SA) filters are used. It's useful to separate HTML e-mail and e-mail with no subject from mailing lists - such posts are usually clueless and don't deserve to be archived, not to mention MS Word attachments. Finally, the messages are put to the mailing list folders, and the remainder goes to the inbox. > IMO it would help a lot, if only people were allowed to send messages to > [EMAIL PROTECTED], who subscribed to the list. No full time administrator > is needed, in fact it would be easy to implement. It's already implemented in Mailman, it's just turned off. However, it would be wrong to reject such messages withot review, and that takes time. -- Regards, Pavel Roskin
acsubst.test, acsubst2.test missing on CVS
Hello, Richard! The current automake doesn't pass the testsuite. The files tests/acsubst.test and tests/acsubst2.test are not on CVS, but the ChangeLog says that you have added them. Please don't forget that you should add the new files by "cvs add" and commit them by "cvs commit". -- Regards, Pavel Roskin
Workaround for bash bug in tests/yacc8.test
Hello! Today's CVS Automake fails in yacc8.test on RedHat Linux 7.2 with bash 2.05.8(1)-release. The failure only happens when VERBOSE=1 is not specified and bash is used. Using ash or pdksh fixes the problem. Even adding a comment between "test" and "cd" fixes the problem. This patch adds "exit 1" - it also increases readability, since "set -e" is far away. ChangeLog: * tests/yacc8.test: Add a command between "test" and "cd" to work around a bug in bash-2.05. === --- tests/yacc8.test +++ tests/yacc8.test @@ -58,7 +58,7 @@ END $AUTOMAKE -a -test -f ./ylwrap +test -f ./ylwrap || exit 1 cd sub make foo/parse2.o === -- Regards, Pavel Roskin
Automake CVS: load average is too high
Hello! Could anybody please check what's going on with Automake CVS? If I'm using anonymous CVS (:pserver:[EMAIL PROTECTED]:/cvs/automake) it almost always fails: $ cvs up Fatal error, aborting. load average of 25 is too high The number varies from 15 to 25. My guess is that there are runaway processes (CPU hogs) on the anoncvs.cygnus.com. Old versions of CVS can create such processes on "cvs log -r," or something like that (I don't want to check it). Since the CVS server doesn't reply to "cvs version", I assume it's old. -- Regards, Pavel Roskin
Re: spam hell
Hello! > We've stopped most of the shit from Korea based on simple filtering, but > it's impossible (or close to) to stop the spam that currently gets through > without closing the list so only subscribers can post or moderating the > postings from non-subscribers. Nobody is interested in the moderator job > I guess, nor am I sure you can even set up moderation with the mailman > mailing list manager. It is possible to set up moderation. Actually, moderation is a wrong word. The only responsibility of the moderator show be preventing spam. It is also possible to improve filtering without restricting posts to the subscribers. In particular, HTML should be banned because of it's potential for abuse. Also there are many headers specific to spam, e.g. "X-Mailer: Caretop" or empty "Date:" There are two things mailman cannot do (as far as I know, without patching it): 1) It cannot check the body of the message. 2) It cannot discard spam without moderator's approval. 3) It cannot combine conditions. > BTW, it's driving me nuts too, but I'm out of filtering ideas... That's what I'm using in my lists: Subject:[ (]*no subject[) ]*$ Subject: *$ Subject: *[A-Za-z]scribe$ Subject:.* .* Subject:.*(product|sex|stock|revenue|sale|rich|toner|manegment|adv) Subject: *(antigen|scanmail) Content-Type: *text/html From: Hahaha <[EMAIL PROTECTED]> X-AD2000-Serial: X-Bulkmail: X-Mailer:.*(Collector|Multi|Gammadyne|Mass|MMailer|AMLC|em5000|V3,|AOL|JCourier|Spam|Mach|Easy|GOTO|Arclab|Caretop) X-EM-Version: X-Courtesy-Of: X-MSMail-Priority: High -- Regards, Pavel Roskin
asm.test fails
Hello! asm.test fails in the CVS version of Automake. $ make check TESTS=asm.test VERBOSE=1 make check-TESTS make[1]: Entering directory `/usr/local/src/automake/tests' === Running test ./asm.test 1 automake: Makefile.am: Assembler source seen but `CCAS' not defined in `configure.in' 2 automake: Makefile.am: Assembler source seen but `CCAS' not defined in `configure.in' 3 automake: Makefile.am: Assembler source seen but `CCAS' not defined in `configure.in' 4 automake: Makefile.am: Assembler source seen but `CCAS' not defined in `configure.in' FAIL: asm.test Obviously, the first 3 steps are supposed to fail, while the steps 4 and 5 should succeed. The changelog has this: * m4/as.m4: Use CCAS and CCASFLAGS. If if means that CCAS and CCASFLAGS are used instead of AS and ASFLAGS respectively, then the following patch should be applied: ChangeLog: * tests/asm.test: Use CCAS and CCASFLAGS instead of AS and ASFLAGS. = --- tests/asm.test +++ tests/asm.test @@ -11,38 +11,38 @@ : > maude.s -# Should fail because we need CC and AS. +# Should fail because we need CC and CCAS. echo 1 cat > configure.in << 'END' AC_INIT AM_INIT_AUTOMAKE(nonesuch, nonesuch) -AC_SUBST(ASFLAGS) +AC_SUBST(CCASFLAGS) AC_OUTPUT(Makefile) END $ACLOCAL || exit 1 $AUTOMAKE && exit 1 -# We still need AS. +# We still need CCAS. echo 2 cat > configure.in << 'END' AC_INIT AM_INIT_AUTOMAKE(nonesuch, nonesuch) AC_PROG_CC -AC_SUBST(ASFLAGS) +AC_SUBST(CCASFLAGS) AC_OUTPUT(Makefile) END $ACLOCAL || exit 1 $AUTOMAKE && exit 1 -# We need ASFLAGS. +# We need CCASFLAGS. echo 3 cat > configure.in << 'END' AC_INIT AM_INIT_AUTOMAKE(nonesuch, nonesuch) -AS='$(CC)' -AC_SUBST(AS) +CCAS='$(CC)' +AC_SUBST(CCAS) AC_PROG_CC AC_OUTPUT(Makefile) END @@ -55,10 +55,10 @@ cat > configure.in << 'END' AC_INIT AM_INIT_AUTOMAKE(nonesuch, nonesuch) -AS='$(CC)' -AC_SUBST(AS) +CCAS='$(CC)' +AC_SUBST(CCAS) AC_PROG_CC -AC_SUBST(ASFLAGS) +AC_SUBST(CCASFLAGS) AC_OUTPUT(Makefile) END = -- Regards, Pavel Roskin
aclocal cannot find /usr/local/share/aclocal-1.5
Hi, Tom! Your recent changes break Automake. In the default configuration, the data files are installed to /usr/local/share/aclocal-1.5c and /usr/local/share/automake-1.5. However, when I run aclocal, it looks for files in /usr/local/share/aclocal-1.5 and cannot find them: aclocal: couldn't open directory `/usr/local/share/aclocal-1.5': No such file or directory Either the aclocal files should be installed in $(datadir)/aclocal-$(APIVERSION) or aclocal should look fort them in $(datadir)/aclocal-$(VERSION) If the former is correct, then the following patch would help: = --- m4/Makefile.am +++ m4/Makefile.am @@ -19,7 +19,7 @@ ## Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA ## 02111-1307, USA. -m4datadir = $(datadir)/aclocal-$(VERSION) +m4datadir = $(datadir)/aclocal-$(APIVERSION) dist_m4data_DATA = as.m4 auxdir.m4 ccstdc.m4 cond.m4 depend.m4 depout.m4 \ dmalloc.m4 gcj.m4 header.m4 init.m4 install-sh.m4 lex.m4 lispdir.m4 \ = Changelog: * m4/Makefile.am (m4datadir): Use APIVERSION. -- Regards, Pavel Roskin
Re: Troubles with PACKAGE_TARNAME
Hello, Alexandre! > 2002-01-12 Alexandre Duret-Lutz <[EMAIL PROTECTED]> > > + * m4/init.m4 (AM_INIT_AUTOMAKE): Set PACKAGE and VERSION from > + AM_INIT_AUTOMAKE arguments when using the old-style call. > + Use AC_PACKAGE_TARNAME and AC_PACKAGE_VERSION in the new form only. > + Suggested by Pavel Roskin. Thank you! It works for me. I didn't know that there is a new form of AM_INIT_AUTOMAKE. However, to use it in GNU Midnight Commander I'll need to be able to redefine PACKAGE_TARNAME because I don't want any spaces in it. This seems to be an Autoconf problem. -- Regards, Pavel Roskin
Troubles with PACKAGE_TARNAME
Hello! GNU Mignight Commander (CVS version) doesn't work correctly with the CVS versions of Autoconf and Automake. "make dist" fails: { test ! -d -4.5.99a || { find -4.5.99a -type d ! -perm -200 -exec chmod u+w {} ';' && rm -fr -4.5.99a; }; } mkdir -4.5.99a mkdir: invalid option -- 4 Try `mkdir --help' for more information. As you can see, the package name "mc" was lost. I found the following string in configure: PACKAGE=midnight commander No wonder that the variable PACKAGE is not set. To reproduce, put this to configure.in: AC_INIT(GNU Midnight Commander, 4.5.99a, [EMAIL PROTECTED]) AM_INIT_AUTOMAKE(mc, 4.5.99a) AC_OUTPUT(Makefile) Create an empty Makefile.am. Run aclocal and autoconf. Search for PACKAGE=midnight in configure. It turns out that _AC_INIT_PACKAGE from Autoconf (file lib/autoconf/general.m4) defines AC_PACKAGE_TARNAME by taking the first argument to AC_INIT, stripping "GNU " and lowering the case. On the other hand, Automake in m4/init.m4 redefines PACKAGE to AC_PACKAGE_TARNAME if the later is defined. I think that Autoconf is wrong here because the name AC_PACKAGE_TARNAME assumes that it should be used in the filename of the distribution tarball. However, the documentation simply explains how it works and doesn't require that there are no spaces other than the one after "GNU". Automake can also be considered wrong because it trusts an Autoconf macro AC_INIT more than Automake macro AM_INIT_AUTOMAKE. I would expect Automake to respect its own macros more that the ones from Autoconf. Maybe the GNU Coding Standards have changed so that spaces are not allowed in the project names? But how about non-GNU projects using Autoconf and Automake? -- Regards, Pavel Roskin
Re: Meta-issue: recent spam surge
> I'm not really comfortable modifying list settings on lists I'm not > "affiliated with", even if I could. The maintainers for those lists > should just pick it up from the mailman settings for the autoconf list... > (It's in the Privacy Settings section). bounce_matching_headers for [EMAIL PROTECTED]: Subject:[ (]*no subject[) ]*$ Subject: *$ Subject: *[A-Za-z]scribe$ Subject:.* .* Subject:.*[^A-Za-z](product|sex|stock|revenue|sale|rich|toner|manegment|adv)[^A-Za-z] Subject: *(antigen|scanmail) Content-Type: *text/html From: Hahaha <[EMAIL PROTECTED]> X-AD2000-Serial: X-Bulkmail: X-Mailer: Email Collector X-EM-Version: X-Courtesy-Of: X-MSMail-Priority: High Should be sufficient if require_explicit_destination is set. -- Regards, Pavel Roskin
Testsuite fails
Hello! The CVS version of Automake fails in libtool2.test. There is no mostlyclean-libtool in sub/Makefile.in. I suggest that if a failing test is submitted, it should be added to XFAIL_TESTS in the same commit. It should be removed from XFAIL_TESTS in the same commit that fixes it. This way we would reserve the true failures for the problems nobody is aware of, so that they can be spotted and reported immediately. -- Regards, Pavel Roskin
Re: CPP determined incorrectly
Hello, Akim! > Pavel> If you feel that you can handle it feel free to merge. It > Pavel> should be done earlier or later anyways. > > So you share my opinion? I share your opinion that AC_PROG_CPP and AC_PROG_CC should be merged eventually. Whether it should be done before Autoconf-2.51 is another question. I personally don't want to risk, but if you think that you can make Automake work with the "big macro" (maybe by releasing another Automake-1.4-pX) without spending months on it then I'll support merging the macros now. -- Regards, Pavel Roskin
Re: CPP determined incorrectly
Hello, Ralf! > > How about merging AC_PROG_CPP and AC_PROG_CC together? > > > > What's the point of keeping the two of them? > * Some tools (eg. imake) apply cpp as macro-processor, even if cc is > not available on a particular installation. Other tools might want > to apply these tools even if not using *.c at all (Eg. using Imake > with non-c-languages). Strictly speaking, it's another problem. In most cases if CPP is needed the best choice is "$CC -E". Testing for CC may be useful even if there are no C files in the project or they aren't used in the core of the project, i.e. lack of working CC is tolerable. I don't care much if we test for CC and don't use it. But I do care that the failure to find CC (CXX, F77) can be tolerated if the package maintainer wants it. In fact, it's not unreasonable to have examples in C++ for a library in C. Typical examle is ncurses. I even remember two (!!!) ways to override the "fatality" of the compiler tests I saw in some projects (don't remember their names, sorry): 1) Use parentheses: (AC_PROG_CXX) 2) Redefine AC_MSG_ERROR. Something like this: define([save_AC_MSG_ERROR], defn([AC_MSG_ERROR])) define([AC_MSG_ERROR], defn([AC_MSG_WARN])) AC_PROG_CXX define([AC_MSG_ERROR], defn([save_AC_MSG_ERROR])) You are right in the sence that calling AC_PROG_CC (i.e. what it is now) form AC_PROG_CPP may force even more people to use such hacks. But it's not what we are discussing. Preprocessor in an integral part of the compiler. Testing the compiler without preprocessor makes no sence. Testing the preprocessor without testing for a working compiler is reasonable, but in many cases "$CC -E" is preferred over /lib/cpp, so it's a good idea to test for the compiler anyways. > * In rare occasions, only a functional cpp is required, but a broken > cc is tolerable (eg. to process *.S -> *.o) If a broken cc is tolerable then you should have a mechanism to instruct configure not to abort. This is quite orthogonal to the preprocessor test. -- Regards, Pavel Roskin
Re: CPP determined incorrectly
Hi, Akim! > Pavel> I have noticed Automake testsuite failures in distname.test, > Pavel> subobj5.test and subobj6.test on OpenBSD 2.7 with the CVS head > Pavel> versions of Autoconf and Automake. > > What's the status of this issue, Pavel? Nothing has changed. The problem persists. There is a useful comment in Automake, file m4/init.m4: # There are a few dirty hacks below to avoid letting `AC_PROG_CC' be # written in clear, in which case automake, when reading aclocal.m4, # will think it sees a *use*, and therefore will trigger all it's # C support machinery. Also note that it means that autoscan, seeing # CC etc. in the Makefile, will ask for an AC_PROG_CC use... I don't think we can expect correct behaior from "dirty hacks" :-( Answering your question from the next message: > How about merging AC_PROG_CPP and AC_PROG_CC together? > What's the point of keeping the two of them? My concern is compatibility. There is no real reason to test for one but not the other, but if we go ahead and merge those macros "a few dirty hacks" may stop working. Another stable release of Automake and/or Libtool may be necessary. If you feel that you can handle it feel free to merge. It should be done earlier or later anyways. -- Regards, Pavel Roskin
CPP determined incorrectly
Hello! First of all, sorry for cross-posting, but as you will see it's hard to decide whether Automake or Autoconf is guilty. I have noticed Automake testsuite failures in distname.test, subobj5.test and subobj6.test on OpenBSD 2.7 with the CVS head versions of Autoconf and Automake. It turns out that configure probes for preprocessor when $CC is empty. /lib/cpp is the last fallback, but OpenBSD doesn't have it. The same tests would pass on Linux, but configure will erroneously set CPP=/lib/cpp. How to reproduce the problem: $ cat <configure.in AC_INIT AM_INIT_AUTOMAKE(nonesuch, 0.23) AC_PROG_CC_C_O AC_OUTPUT EOF $ aclocal; automake -a; autoconf $ ./configure | grep /lib/cpp > checking how to run the C preprocessor... /lib/cpp The problem goes away if Automake 1.4 is used (actually, aclocal from Automake 1.4). It appears that AM_INIT_AUTOMAKE does something with AC_PROG_CC so that the later cannot be AC_REQUIRE'd. This configure.in would exhibit the problem as well: AC_INIT AC_DEFUN([AC_FOO], [AC_REQUIRE([AC_PROG_CC])]) AM_INIT_AUTOMAKE(nonesuch, 0.23) AC_FOO AC_OUTPUT I don't know whether Autoconf should be more robust or Automake should take less (or more?) hackerish approach. Since Autoconf-2.50 has been released, it would be fair to drop support for Autoconf-2.13 and use new facilities for attaching dependency code to AC_PROG_CC (provided that they exist and I understand the problem correctly). -- Regards, Pavel Roskin
depcomp used but not installed
Hello! The conditions under which Automake installs and uses the "depmod" script are different. It can actually happen that it's not installed but configure tries to use it. For example, GNU Midnight Commander is using Automake only on the top level and for data directories. Automake doesn't see any C files in the Makefile.am, so it decides not to install depmod. But since AC_PROG_CC is used, configure tries to use depcomp. I've written depcomp2.test that demonstrates the problem. Actually, I don't know how it should be fixed. Either depcomp should be installed just in case or AM_DEPENDENCIES should be more quiet if it cannot find depcomp. Anyway, this test demonstrates error messages from "configure" - this certainly shouldn't happen. -- Regards, Pavel Roskin __ #! /bin/sh # Test to make sure that depcomp is not used when it's not installed # From Pavel Roskin. . $srcdir/defs || exit 1 cat > configure.in << 'END' AC_INIT(subdir/foo.c) AM_INIT_AUTOMAKE(nonesuch, nonesuch) PACKAGE=nonesuch VERSION=nonesuch AC_PROG_CC AC_OUTPUT(Makefile subdir/Makefile) END cat > Makefile.am << 'END' SUBDIRS = subdir END rm -f depcomp mkdir subdir cat > subdir/Makefile.in << 'END' foo: $(CC) -o foo foo.c END : > subdir/foo.c # Fail gracefully if no autoconf. $needs_autoconf # Likewise for gcc. (gcc -v) > /dev/null 2>&1 || exit 77 $ACLOCAL || exit 1 $AUTOMAKE --add-missing || exit 1 $AUTOCONF || exit 1 CC='gcc' ./configure 2>error.log test -z "`cat error.log`" __
Re: Patch to allow spaces before double hashes
> > Could you submit a PR with this info in it? > > Sorry, GNATS doesn't appear to work now. It shows that the PR has been > submitted (it would be nice if it at least would show the PR number), but > the PR it doesn't appear in the new query result. It works, just not immediately as it used to be. It's PR/174. -- Regards, Pavel Roskin
Re: Patch to allow spaces before double hashes
Hi, Tom! > Could you submit a PR with this info in it? Sorry, GNATS doesn't appear to work now. It shows that the PR has been submitted (it would be nice if it at least would show the PR number), but the PR it doesn't appear in the new query result. Important detail - I'm logged in under my name "proski" but I don't have edit access to Automake database. > Ok, thanks. > Could you see if the manual needs to be updated for this? Yes. The submitted patch updates the documentation. -- Regards, Pavel Roskin --- ChangeLog 2001/05/14 12:14:37 1.1362 +++ ChangeLog 2001/05/14 16:14:58 1.1363 @@ -1,3 +1,9 @@ +2001-05-13 Pavel Roskin <[EMAIL PROTECTED]> + + * automake.in ($IGNORE_PATTERN): Allow spaces before comments + beginning with `##'. + * automake.texi (General Operation): Document it. + 2001-05-13 Tom Tromey <[EMAIL PROTECTED]> Reported by Rainer Orth: --- automake.in 2001/05/14 04:48:43 1.1119 +++ automake.in 2001/05/14 16:15:02 1.1120 @@ -110,7 +110,7 @@ my $libdir = "@datadir@/@PACKAGE@"; # String constants. -my $IGNORE_PATTERN = '^##([^#\n].*)?\n'; +my $IGNORE_PATTERN = '^\s*##([^#\n].*)?\n'; my $WHITE_PATTERN = '^\s*$'; my $COMMENT_PATTERN = '^#'; my $TARGET_PATTERN='[$a-zA-Z_.][-.a-zA-Z0-9_(){}/$]*'; --- automake.texi 2001/05/14 04:48:43 1.206 +++ automake.texi 2001/05/14 16:15:03 1.207 @@ -271,8 +271,8 @@ @cindex Comment, special to Automake Automake also allows a form of comment which is @emph{not} copied into -the output; all lines beginning with @samp{##} are completely ignored by -Automake. +the output; all lines beginning with @samp{##} (leading spaces allowed) +are completely ignored by Automake. It is customary to make the first line of @file{Makefile.am} read:
gcj.test fails unexpectedly
Hello! gcj.test fails unexpectedly in the CVS automake on RedHat 7.1. $ make check TESTS=gcj.test VERBOSE=1 make check-TESTS make[1]: Entering directory `/usr/local/src/automake/tests' === Running test ./gcj.test /home/proski/src/automake/tests/../depend2.am: AMDEP does not appear in AM_CONDITIONAL FAIL: gcj.test === 1 of 1 tests failed === make[1]: *** [check-TESTS] Error 1 make[1]: Leaving directory `/usr/local/src/automake/tests' make: *** [check-am] Error 2 -- Regards, Pavel Roskin
Patch to allow spaces before double hashes
Hello! It seems to be a pointless requirement that the comments in Makefile.am begin strictly at the line start, even if they don't appear in Makefile,in. It can often be useful to place a comment as near as possible to the line being commented but preserve the indentation. It should now be possible with the proposed patch. Automake should probably warn about indented comments that go to Makefile.in, as they may be non-portable. I just saw a report in [EMAIL PROTECTED] that Compaq Tru64 UNIX V5.1 doesn't like '&' in such comments, most likely because they are actully fed to the shell. But this is out of scope of the proposed patch. ChangeLog: * automake.in ($IGNORE_PATTERN): Allow spaces before double hash. _ --- automake.in +++ automake.in @@ -111,7 +111,7 @@ my $pkgdata_dir = "@datadir@/@PACKAGE@"; # String constants. -my $IGNORE_PATTERN = '^##([^#\n].*)?\n'; +my $IGNORE_PATTERN = '^\s*##([^#\n].*)?\n'; my $WHITE_PATTERN = '^\s*$'; my $COMMENT_PATTERN = '^#'; my $TARGET_PATTERN='[$a-zA-Z_.][-.a-zA-Z0-9_(){}/$]*'; _ Regards, Pavel Roskin
Re: automake-1.4-p1
Hello, Gary! Thank you very much for this release! The stable release should have been released soon after 1.4 but it wasn't done. I really appreciate that you came and did it. One little problem. If I put "AUTOMAKE_OPTIONS = 1.4-p1" to the Makefile.am and run CVS Automake I'm getting Makefile.am:3: require version 1.4-p1, but have 1.4e What is even worse is that if I "re-brand" CVS automake to version 1.5 or even 2.0 it still refuses to process that Makefile.am: Makefile.am:3: require version 1.4-p1, but have 2.0 I understand it's a problem in CVS (HEAD branch) Automake and should be fixed there. > * Directories listed in EXTRA_DIST are now correctly included > in the generated distribution tarball. This is the reason why I would like to have "AUTOMAKE_OPTIONS = 1.4-p1" in some projects. -- Regards, Pavel Roskin
FYI: Unescaped $(LIBTOOL)
Hello! The CVS Libtool doesn't compile with CVS Automake. This is the first (and probably the easiest) problem I faced. I'm applying the patch. It was funny to see 502 in makefiles and wonder what it might be :-) ChangeLog: * automake.in (define_compiler_variable): Escape $(LIBTOOL) in double quotes. _ --- automake.in +++ automake.in @@ -6286,7 +6286,7 @@ my ($var, $value) = ($lang->compiler, $lang->compile); &define_variable ($var, $value); -&define_variable ("LT$var", "$(LIBTOOL) --mode=compile $value") +&define_variable ("LT$var", "\$(LIBTOOL) --mode=compile $value") if $seen_libtool; } _ Regards, Pavel Roskin
Enabling --Werror in the testsuite (Was: automake/149)
Hi, Tom! > Oops, I broke it. Akim checked in the fix. Now it works. I can use "--Werror --add-missing". Thank you for taking care of the problem! The next thing I tried was adding "--Werror" to the automake flags in tests/defs. Just four tests now fail unexpectedly (due to warnings that are now errors): condincl.test dash.test include.test texinfo8.test Warnings are: Use of uninitialized value in pattern match (m//) at ../../automake line 6570. (first three tests) Use of uninitialized value in split at ../../automake line 3185. (texinfo8.test) When they are fixed it will be possible to use "--Werror" in the testuite. Or we can just add those tests to XFAIL_TESTS and enable "--Werror" now. -- Regards, Pavel Roskin
Re: Warning fix for automake on CVS Libtool
Hello, Akim! > | Don't you know that Automake has its > | documentation in the top-level directory? > > I would like to move the documentation into doc/ in Automake. OK with > that? Same problem as for *.am files, Tom, we need to move them on > the CVS server if we want to keep the history. Un-flattenning Automake is probably a good idea, but the history is a serious concern, especially considering that the output of "cvs annotate" will be affected. I would do everything as the cvs manual suggests, i.e. "cvs add" and "cvs remove". I'd rather tolerate some inconvenience than mess with the "historical truth", i.e. with the history of the project as a whole. But if you value history of individual files more than that of the project I suggest (as my second best preference) copying those files in the repository and then removing the old files using "cvs remove". This way, the historic versions will have extra files in the subdirs but "make" will not descent into them and neither will "make dist". -- Regards, Pavel Roskin
Re: Warning fix for automake on CVS Libtool
On 5 May 2001, Tom Tromey wrote: > I think this is ok. > Please check it in. Ok. > Pavel> + elsif (/^\@def(code)?index (\w+)/) > Pavel> +push @clean_suffixes, $2; > > My understanding is that here $1 will not necessarily be defined, but > $2 will always be defined. Is that right? Yes. I was 99.9% sure, but since you asked I wrote this script and it makes me 100% sure. #! /usr/bin/perl -w $_ = "\@defcodeindex fu"; /^\@def(code)?index (\w+)/; print "\$1 = $1, \$2 = $2\n"; $_ = "\@defindex fu"; /^\@def(code)?index (\w+)/; print "\$1 = $1, \$2 = $2\n"; Output: $1 = code, $2 = fu Use of uninitialized value in concatenation (.) at ./test line 7. $1 = , $2 = fu > Pavel> By the way, I discovered a terrible bug in CVS Automake while > Pavel> testing it - "make dvi" doesn't propagate to the > Pavel> subdirectories. > > That's a bit suprising. I looked at the automake Makefile.in and it > seems to do the right thing. `make -n dvi' seemed to work ok too. Tom, I'm worried about you. Don't you know that Automake has its documentation in the top-level directory? Try recent Autoconf or Libtool: $ automake $ ./configure --quiet ... $ make dvi make: Nothing to be done for `dvi'. -- Regards, Pavel Roskin
Re: Warning fix for automake on CVS Libtool
Hi, Tom! > Pavel> -push @clean_suffixes, $predefined_index{$1}; > Pavel> +push @clean_suffixes, $predefined_index{$1} > Pavel> +if (defined $predefined_index{$1}); > > I think any possible value here is already defined. > So the `if' is not required. The warnings were only from %hidden_index, but I was under impression that some protection is needed here as well. I missed the "[cfkvtp]" part in the regular expression. Sorry. > Pavel> -push @clean_suffixes, $hidden_index{$1}; > Pavel> +push @clean_suffixes, $hidden_index{$1} > Pavel> +if (defined $hidden_index{$1}); > > I think this is actually ok. I tend to agree. Automake is not required to check texinfo files and warn about their contents - other tools exist for that. Not cleaning few files is not a big deal since correctness of "make dist" doesn't rely on correctness of "make distclean" and the later is ensured by "make distcheck". > Akim, I notice that while @defcodeindex is handled, @defindex is not. > Is that intentional, or just an oversight? >From reading the documenation for texinfo it seems to be an oversight. The difference between @defcodeindex and @defindex is purely cosmetical. The save applies to @syncodeindex vs. @synindex. Almost untested patch (in produces no warnings, that's all I know): ChangeLog: * automake.in (scan_texinfo_file): Consider @defindex and @synindex in the same way as @defcodeindex and @syncodeindex respectively. ___ --- automake.in +++ automake.in @@ -2601,9 +2601,9 @@ # Try to find what are the indexes which are used. # Creating a new category of index. - elsif (/^\@defcodeindex (\w+)/) + elsif (/^\@def(code)?index (\w+)/) { -push @clean_suffixes, $1; +push @clean_suffixes, $2; } # Storing in a predefined index. @@ -2618,9 +2618,9 @@ } # Merging an index into an another. - elsif (/^\@syncodeindex (\w+) \w+/) + elsif (/^\@syn(code)?index (\w+) \w+/) { - push @syncodeindexes, "$1s"; + push @syncodeindexes, "$2s"; } } ___ By the way, I discovered a terrible bug in CVS Automake while testing it - "make dvi" doesn't propagate to the subdirectories. -- Regards, Pavel Roskin
Re: tiny patch to make automake find Automake/Struct.pm
Hello, Jim! I was the first to send the patch but your description is better. > 2001-04-30 Jim Meyering <[EMAIL PROTECTED]> > > * automake.in: Remove `/lib' from include directory. Applied. -- Regards, Pavel Roskin
CVS Automake cannot find Struct.pm
Hello! CVS Automake passes the testsuite but doesn't work at all in the "real life". For the default prefix, it's trying to find Automake/Struct.pm in /usr/local/share/automake/lib instead of /usr/local/share/automake ChangeLog: * automake.in (BEGIN): Don't append "/lib" to the Perl include path. _ --- automake.in +++ automake.in @@ -32,7 +32,7 @@ BEGIN { my $prefix = "@prefix@"; - my $perllibdir = $ENV{'perllibdir'} || "@datadir@/@PACKAGE@/lib"; + my $perllibdir = $ENV{'perllibdir'} || "@datadir@/@PACKAGE@"; unshift @INC, "$perllibdir"; } _ Regards, Pavel Roskin
Re: Warning fix for automake on CVS Libtool
Hello! > This patch eliminates pushing undefined values to an array of suffixes to > be cleaned for texinfo files. It seems that my patch is not quite correct. It eliminates a warning that possibly indicates a logic error. It's better to fix the problem than to hide it. > -push @clean_suffixes, $hidden_index{$1}; > +push @clean_suffixes, $hidden_index{$1} > + if (defined $hidden_index{$1}); I doubt that we should just go ahead without taking any action if for @defxxx we cannot find xxx in %hidden_index. I'll be busy today, but I promise to look into this later. I'll be grateful is somebody with better knowledge of texinfo checks my patch in the meantime. -- Regards, Pavel Roskin
Warning fix for automake on CVS Libtool
Hello! This patch eliminates pushing undefined values to an array of suffixes to be cleaned for texinfo files. This fixes the warnings automake produces when it's run on the CVS Libtool sources. ChangeLog: * automake.in (scan_texinfo_file): Don't push undefined values to @clean_suffixes. ___ --- automake.in +++ automake.in @@ -2596,11 +2596,13 @@ # Storing in a predefined index. elsif (/^\@([cfkvtp])index /) { -push @clean_suffixes, $predefined_index{$1}; +push @clean_suffixes, $predefined_index{$1} + if (defined $predefined_index{$1}); } elsif (/^\@def(\w+) /) { -push @clean_suffixes, $hidden_index{$1}; +push @clean_suffixes, $hidden_index{$1} + if (defined $hidden_index{$1}); } # Merging an index into an another. ___ -- Regards, Pavel Roskin
Re: register_language() ?
On 24 Apr 2001, Tom Tromey wrote: > Pavel> This patch has been tested with Perl perl5.005_03 and 5.6.0. Ok > Pavel> to apply? > > Akim> Fine with me. > > Me too. Thanks. Applied after a short fight with CVS. The version you are using on sourceware.cygnus.com tends to commit only some of the files in a single run (either only those from the current directory or all files except those from the current directory). The CVS on sourceware.cygnus.com must be very old since it has another bug that I fixed almost 2 years ago: $ cvs log -r automake.in Terminated with fatal signal 11 Unrelated question - why does the prototype use `$%' instead of `%'? We are only using hashes as arguments. Actually, prototype checking seems to be rather weak, but it's better than nothing. -- Regards, Pavel Roskin
Re: register_language() ?
Hello, Patrick! > I just did a cvs checkout of automake, all the tests pass, but believe it > or not: In fact, installsh.test fails, but it's an _expected_ failure. I'm probably missing something, since I have no time to catch up with the mailing list, but what's wrong with the forward declarations, as described in "man perlsub"? This patch has been tested with Perl perl5.005_03 and 5.6.0. Ok to apply? ChangeLog: * automake.in: Add a forward declaration for register_language(). * tests/Makefile.am (XFAIL_TESTS): Remove installsh.test - it passes now. __ --- automake.in +++ automake.in @@ -603,6 +603,13 @@ # FIXME: This is a hack. a better switch should be found. my $get_object_extension_was_run; + +## - ## +## Forward subroutine declarations. ## +## - ## +sub register_language ($%); + + # &initialize_per_input () # # (Re)-Initialize per-Makefile.am variables. --- tests/Makefile.am +++ tests/Makefile.am @@ -2,14 +2,7 @@ AUTOMAKE_OPTIONS = gnits -# installsh.test -# Currently Perl 5.6 complains because register_language is used before -# being defined. It's only a warning, and this warning will be naturally -# solved later (either when we move register_language, or when Languages -# are actual classes, not objects). But installsh checks automake's -# stderr, which includes these complaints from Perl. -# So just forget about it now. -XFAIL_TESTS = installsh.test man.test objc.test subobj2.test yaccvpath.test +XFAIL_TESTS = man.test objc.test subobj2.test yaccvpath.test TESTS =\ acinclude.test \ ______ -- Regards, Pavel Roskin
subobj2.test fails
Hello! With the today's CVS automake the testsuite fails in subobj2.test on my RedHat Linux 7. $ make check TESTS=subobj2.test VERBOSE=1 make check-TESTS make[1]: Entering directory `/home/proski/src/automake/tests' === Running test ./subobj2.test Makefile.am:0: @AMDEP@CXXDEPMODE multiply defined in condition TRUE @AMDEP@CXXDEPMODE (Automake, where = 0) = { TRUE => @CXXDEPMODE@ } FAIL: subobj2.test === 1 of 1 tests failed === make[1]: *** [check-TESTS] Error 1 make[1]: Leaving directory `/home/proski/src/automake/tests' make: *** [check-am] Error 2 The failure happens during the "automake" invocation. Makefile.in is created and contains the following string twice: @AMDEP@CXXDEPMODE = @CXXDEPMODE@ Regards, Pavel Roskin
--Werror and --add-missing don't work toghether
Hello! CVS Automake uses am_line_error() to inform the user that it's installing files. As a result, --Werror causes Automake to exit after it installs the first file: $ automake --Werror --add-missing; echo $? automake: Makefile.am: installing `./INSTALL' 2 $ automake --Werror --add-missing; echo $? automake: Makefile.am: required file `./NEWS' not found 2 Sorry, no patch. Regards, Pavel Roskin
Re: FYI: `make distcheck' non-interactive again
Hello! > ChangeLog: > * Makefile.am (maintainer-check): Scan all *.am files and tests > for invocations of `rm' without `-f'. > * tests/mclean.test: Adjusted to prevent being caught by the > above test. I've checked it in. Regards, Pavel Roskin
Re: FYI: `make distcheck' non-interactive again
Hello, Tom! > Pavel> `make distcheck' is working again. No more questions from `rm'. > > Thanks. > BTW this is the sort of thing that we can check for in > `maintainer-check'. That way we can easily find out if we've > accidentally written a new test that will break. I don't know if `maintainer-check' can rely on egrep being GNU egrep. If yes, here's the patch. Ideally, maintainer-check should be another test in tests/ written entirely in Perl. ChangeLog: * Makefile.am (maintainer-check): Scan all *.am files and tests for invocations of `rm' without `-f'. * tests/mclean.test: Adjusted to prevent being caught by the above test. --- Makefile.am +++ Makefile.am @@ -79,6 +79,13 @@ echo "Found too many uses of '\$${' in the lines above." 1>&2; \ exit 1; \ else :; fi +## Make sure `rm' is called with `-f'. + @if egrep '\)' \ + $(srcdir)/[a-z]*.am $(srcdir)/tests/*.test | \ + fgrep -v '##'; then \ + echo "Suspicious 'rm' invocation." 1>&2; \ + exit 1; \ + else :; fi ## Make sure all invocations of mkinstalldirs are correct. @if fgrep -n 'mkinstalldirs' $(srcdir)/[a-z]*.am | \ fgrep -v '$$(mkinstalldirs)'; then \ --- tests/mclean.test +++ tests/mclean.test @@ -13,4 +13,4 @@ $AUTOMAKE || exit 1 -grep 'rm .*MAINTAINERCLEANFILES' Makefile.in +grep 'rm -f .*MAINTAINERCLEANFILES' Makefile.in Regards, Pavel Roskin
Re: FYI: `make distcheck' non-interactive again
Hello, Tom! > Thanks. > BTW this is the sort of thing that we can check for in > `maintainer-check'. That way we can easily find out if we've > accidentally written a new test that will break. Libtool has a test (sh.test) that checks for suspicious constructs in ltmain.sh. But it would be harder to process *.am and automake.in. Speaking of "rm" without "-f", there is one more place where it can be found. ChangeLog: * java.am: Use `rm -f' instead of `rm'. --- java.am +++ java.am @@ -53,4 +53,4 @@ .PHONY clean-am: clean-%DIR%JAVA: clean-%DIR%JAVA: - -rm *.class class%DIR%.stamp + -rm -f *.class class%DIR%.stamp Regards, Pavel Roskin
Re: CVS Automake installs noinst_SCRIPTS.
On 6 Mar 2001, Akim Demaille wrote: > Pavel Roskin <[EMAIL PROTECTED]> writes: > > > .PHONY uninstall-am: uninstall-%DIR%SCRIPTS > > I fixed this typo (missing ?INSTALL?). Thanks! I've removed noinstdir.test from XFAIL_TESTS. Regards, Pavel Roskin
Re: CVS Automake installs noinst_SCRIPTS.
for p in $$list; do \ +?INSTALL?f="`echo $$p|sed '$(transform)'`"; \ +?INSTALL?if test -f $$p; then \ +?INSTALL? echo " $(INSTALL_SCRIPT) $$p $(DESTDIR)$(%NDIR%dir)/$$f"; \ +?INSTALL? $(INSTALL_SCRIPT) $$p $(DESTDIR)$(%NDIR%dir)/$$f; \ +?INSTALL?elif test -f $(srcdir)/$$p; then \ +?INSTALL? echo " $(INSTALL_SCRIPT) $(srcdir)/$$p +$(DESTDIR)$(%NDIR%dir)/$$f"; \ +?INSTALL? $(INSTALL_SCRIPT) $(srcdir)/$$p $(DESTDIR)$(%NDIR%dir)/$$f; \ +?INSTALL?else :; fi; \ +?INSTALL? done .PHONY uninstall-am: uninstall-%DIR%SCRIPTS -uninstall-%DIR%SCRIPTS: - @$(NORMAL_UNINSTALL) - @list='$(%DIR%_SCRIPTS)'; for p in $$list; do \ - f="`echo $$p|sed '$(transform)'`"; \ - echo " rm -f $(DESTDIR)$(%NDIR%dir)/$$f"; \ - rm -f $(DESTDIR)$(%NDIR%dir)/$$f; \ - done +?INSTALL?uninstall-%DIR%SCRIPTS: +?INSTALL? @$(NORMAL_UNINSTALL) +?INSTALL? @list='$(%DIR%_SCRIPTS)'; for p in $$list; do \ +?INSTALL?f="`echo $$p|sed '$(transform)'`"; \ +?INSTALL?echo " rm -f $(DESTDIR)$(%NDIR%dir)/$$f"; \ +?INSTALL?rm -f $(DESTDIR)$(%NDIR%dir)/$$f; \ +?INSTALL? done ## Uncomment line in handle_scripts when this is uncommented. ## check-%DIR%SCRIPTS: __ Regards, Pavel Roskin
FYI: `make distcheck' non-interactive again
Hello! `make distcheck' is working again. No more questions from `rm'. Regards, Pavel Roskin __ Index: ChangeLog === RCS file: /cvs/automake/automake/ChangeLog,v retrieving revision 1.1149 retrieving revision 1.1150 diff -u -r1.1149 -r1.1150 --- ChangeLog 2001/03/05 22:11:04 1.1149 +++ ChangeLog 2001/03/06 00:48:20 1.1150 @@ -1,5 +1,15 @@ 2001-03-05 Pavel Roskin <[EMAIL PROTECTED]> + * tests/copy.test: Never use `rm' without `-f' - it may ask + questions, notably for read-only files during `make distcheck'. + * tests/insh.test: Likewise. + * tests/installsh.test: Likewise. + * tests/symlink.test: Likewise. + * tests/symlink2.test: Likewise. + * tests/symlink3.test: Likewise. + +2001-03-05 Pavel Roskin <[EMAIL PROTECTED]> + * noinstdir.test: New test. * tests/Makefile.am (TESTS): Add noinstdir.test. (XFAIL_TESTS): Likewise. Index: tests/copy.test === RCS file: /cvs/automake/automake/tests/copy.test,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- copy.test 1999/01/22 14:14:48 1.1 +++ copy.test 2001/03/06 00:48:20 1.2 @@ -5,6 +5,6 @@ . $srcdir/defs || exit 1 : > Makefile.am -rm install-sh +rm -f install-sh $AUTOMAKE -c -a Index: tests/insh.test === RCS file: /cvs/automake/automake/tests/insh.test,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- insh.test 1996/04/03 22:16:37 1.1 +++ insh.test 2001/03/06 00:48:20 1.2 @@ -5,7 +5,7 @@ . $srcdir/defs || exit 1 -rm mkinstalldirs +rm -f mkinstalldirs : > Makefile.am Index: tests/installsh.test === RCS file: /cvs/automake/automake/tests/installsh.test,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- installsh.test 1999/02/01 11:49:56 1.2 +++ installsh.test 2001/03/06 00:48:20 1.3 @@ -7,7 +7,7 @@ . $srcdir/defs || exit 1 : > Makefile.am -rm install-sh +rm -f install-sh # Since the default path includes '../..', we must run this test in # yet another subdir. Index: tests/symlink.test === RCS file: /cvs/automake/automake/tests/symlink.test,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- symlink.test1999/08/27 05:42:19 1.2 +++ symlink.test2001/03/06 00:48:20 1.3 @@ -5,8 +5,8 @@ . $srcdir/defs || exit 1 -rm install-sh -rm mkinstalldirs +rm -f install-sh +rm -f mkinstalldirs : > Makefile.am Index: tests/symlink2.test === RCS file: /cvs/automake/automake/tests/symlink2.test,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- symlink2.test 2000/03/19 22:24:26 1.1 +++ symlink2.test 2001/03/06 00:48:20 1.2 @@ -4,8 +4,8 @@ . $srcdir/defs || exit 1 -rm install-sh -rm mkinstalldirs +rm -f install-sh +rm -f mkinstalldirs ln -s Zardoz mkinstalldirs : > Makefile.am Index: tests/symlink3.test === RCS file: /cvs/automake/automake/tests/symlink3.test,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- symlink3.test 2000/03/19 22:33:19 1.1 +++ symlink3.test 2001/03/06 00:48:20 1.2 @@ -4,8 +4,8 @@ . $srcdir/defs || exit 1 -rm install-sh -rm mkinstalldirs +rm -f install-sh +rm -f mkinstalldirs echo zot > zot echo zot > mkinstalldirs __
CVS Automake installs noinst_SCRIPTS.
Hello! CVS Automake attempts to install noinst_SCRIPTS. The following test fails: ___ #! /bin/sh # Test to make sure that noinst_SCRIPTS are not installed. # From Pavel Roskin. . $srcdir/defs || exit 1 cat > Makefile.am << 'END' noinst_SCRIPTS = foo END $AUTOMAKE || exit 1 grep 'noinstdir' Makefile.in && exit 1 exit 0 _______ Regards, Pavel Roskin
FYI: configure.am not installed
Hello, Akim! configure.am is a wonderful name (how long before we see Makefile.ac?), but you forgot to add in to Makefile.am Rebuilding makefiles discovers an interesting side effect - OBJEXT and EXEEXT are now defined in Makefile.in as constants. I had to commit them, but please make sure that it's what you want to happen. Regards, Pavel Roskin ___ Index: ChangeLog === RCS file: /cvs/automake/automake/ChangeLog,v retrieving revision 1.1143 retrieving revision 1.1144 diff -u -r1.1143 -r1.1144 --- ChangeLog 2001/03/05 15:02:58 1.1143 +++ ChangeLog 2001/03/05 16:57:51 1.1144 @@ -1,3 +1,7 @@ +2001-03-05 Pavel Roskin <[EMAIL PROTECTED]> + + * Makefile.am (amfiles): Add configure.am. Sort alphabetically. + 2001-03-05 Akim Demaille <[EMAIL PROTECTED]> If OBJEXT and EXEEXT are not set, provide a default value, and use Index: Makefile.am === RCS file: /cvs/automake/automake/Makefile.am,v retrieving revision 1.151 retrieving revision 1.152 diff -u -r1.151 -r1.152 --- Makefile.am 2001/03/05 14:49:43 1.151 +++ Makefile.am 2001/03/05 16:57:52 1.152 @@ -11,13 +11,13 @@ info_TEXINFOS = automake.texi amfiles = check.am clean-hdr.am clean-kr.am clean.am comp-vars.am \ -compile.am data-clean.am data.am dejagnu.am depend.am depend2.am \ -distdir.am footer.am header-vars.am header.am install.am \ +compile.am configure.am data-clean.am data.am dejagnu.am depend.am \ +depend2.am distdir.am footer.am header-vars.am header.am install.am \ java-clean.am java.am kr-extra.am library.am libs-clean.am libs.am \ libtool.am lisp-clean.am lisp.am ltlib-clean.am ltlib.am ltlibrary.am \ mans-vars.am mans.am multilib.am program.am progs-clean.am progs.am \ -python.am python-clean.am remake-hdr.am remake.am scripts.am \ -subdirs.am tags-clean.am tags.am texi-vers.am texinfos.am texibuild.am +python-clean.am python.am remake-hdr.am remake.am scripts.am \ +subdirs.am tags-clean.am tags.am texi-vers.am texibuild.am texinfos.am dist_pkgdata_DATA = COPYING INSTALL texinfo.tex ansi2knr.c ansi2knr.1 \ $(amfiles) Index: Makefile.in === RCS file: /cvs/automake/automake/Makefile.in,v retrieving revision 1.291 retrieving revision 1.292 diff -u -r1.291 -r1.292 --- Makefile.in 2001/03/05 14:49:43 1.291 +++ Makefile.in 2001/03/05 17:05:26 1.292 @@ -85,13 +85,13 @@ info_TEXINFOS = automake.texi amfiles = check.am clean-hdr.am clean-kr.am clean.am comp-vars.am \ -compile.am data-clean.am data.am dejagnu.am depend.am depend2.am \ -distdir.am footer.am header-vars.am header.am install.am \ +compile.am configure.am data-clean.am data.am dejagnu.am depend.am \ +depend2.am distdir.am footer.am header-vars.am header.am install.am \ java-clean.am java.am kr-extra.am library.am libs-clean.am libs.am \ libtool.am lisp-clean.am lisp.am ltlib-clean.am ltlib.am ltlibrary.am \ mans-vars.am mans.am multilib.am program.am progs-clean.am progs.am \ -python.am python-clean.am remake-hdr.am remake.am scripts.am \ -subdirs.am tags-clean.am tags.am texi-vers.am texinfos.am texibuild.am +python-clean.am python.am remake-hdr.am remake.am scripts.am \ +subdirs.am tags-clean.am tags.am texi-vers.am texibuild.am texinfos.am dist_pkgdata_DATA = COPYING INSTALL texinfo.tex ansi2knr.c ansi2knr.1 \ @@ -116,6 +116,8 @@ WGET = wget FETCHFILES = config.guess config.sub +EXEEXT = +OBJEXT = o subdir = . ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs Index: m4/Makefile.in === RCS file: /cvs/automake/automake/m4/Makefile.in,v retrieving revision 1.136 retrieving revision 1.137 diff -u -r1.136 -r1.137 --- Makefile.in 2001/03/05 14:45:39 1.136 +++ Makefile.in 2001/03/05 17:05:26 1.137 @@ -88,6 +88,8 @@ EXTRA_DIST = $(m4data_DATA) +EXEEXT = +OBJEXT = o subdir = m4 mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs CONFIG_CLEAN_FILES = Index: tests/Makefile.in === RCS file: /cvs/automake/automake/tests/Makefile.in,v retrieving revision 1.353 retrieving revision 1.354 diff -u -r1.353 -r1.354 --- Makefile.in 2001/03/05 14:45:40 1.353 +++ Makefile.in 2001/03/05 17:05:26 1.354 @@ -357,6 +357,8 @@ EXTRA_DIST = defs ChangeLog-old $(TESTS) +EXEEXT = +OBJEXT = o subdir = tests mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs CONFIG_CLEAN_FILES =
Re: CVS Automake breaks with perl5.6.0
Hello, Akim! > > Obviously, %require_file_found should be declared by "use vars", but I > > would prefer if the author does it. In fact, it may be a legitimate case > > for a variable to be declared local. > > You tried in the middle of a batch of patches. It was fixed before > your message arrived. See my messages about require_file_found. Great! I wish your answer about the next problem would be the same! Only one test is failing now - installsh.test. Perl reports the same mesages many times, so I ran the output through sort and uniq. $ make check TESTS=installsh.test VERBOSE=1 2>&1 | sort | uniq 1 of 1 tests failed === Running test ./installsh.test === FAIL: installsh.test Use of uninitialized value in concatenation (.) at ../../../automake line 3426. Use of uninitialized value in concatenation (.) at ../../../automake line 4092. Use of uninitialized value in concatenation (.) at ../../../automake line 6768. Use of uninitialized value in quotemeta at ../../../automake line 6839. Use of uninitialized value in string ne at ../../../automake line 6651. make check-TESTS make: *** [check-am] Error 2 make[1]: *** [check-TESTS] Error 1 make[1]: Entering directory `/home/proski/src/automake.v0/tests' make[1]: Leaving directory `/home/proski/src/automake.v0/tests' Regards, Pavel Roskin
CVS Automake breaks with perl5.6.0
Hello! Automake from CVS doesn't work with perl5.6.0 today: $ perl5.6.0 -c automake Global symbol "%require_file_found" requires explicit package name at automake line 3291. BEGIN not safe after errors--compilation aborted at automake line 3830. Obviously, %require_file_found should be declared by "use vars", but I would prefer if the author does it. In fact, it may be a legitimate case for a variable to be declared local. Regards, Pavel Roskin
Re: yaccvpath.test
Hello, Tom! Thank you for your answers! When I asked them I didn't realize that the point of yaccvpath.test was not failed "make distcheck", but an out-of-date file appearing in the tarball. Anyway, I'm glad to see that our views are very similar. > Pavel> 1) "make dist" must ensure that out-of-date generated > Pavel> distributable files (parser.c, Makefile.in etc) are not > Pavel> included in the tarball either by running "make all" or > Pavel> otherwise. Yes or no? > > Yes. This has been on the to-do list for a long time. > I don't recall what has been holding it up. I do misuse this shortcut ("make dist" before "make all") but I know what I'm doing, which may not be the case for other people. I'm ready to accept some personal inconvenience in exchange for the better quality of software using Automake :-) > Pavel> 2) "make distcheck" must ensure that out-of-date generated > Pavel> distributable files are not included in the tarball by exiting > Pavel> with non-zero code. Yes or no? > > It would be nice but this is probably very hard, since the user can > add random targets to build just about anything. This is reasonable since you answer "yes" to the first question. "make all" should guarantee it and "make dist" should rely on it. > Pavel> 3) Out-of-date generated distributable files should be > Pavel> recreated in the build directory. Always, never, only when no > Pavel> write permissions for srcdir? ... > For yacc/lex output the answer probably depends on what the user wants > to happen. For instance you might have one answer for the developer > and another answer after unpacking a `dist' tarball. If we need it with the `dist' tarball it's a big problem with that tarball. I won't mind a failure at this point. I like you approach to do "what the user wants", I just don't see a situation where anybody would want to create a file in builddir instead of overwriting it in srcdir (or attempting to do so with a subsequent failure). > Pavel> 4) "make distclean" should attempt to clean generated > Pavel> distributable files that appear in the build directory. Yes or > Pavel> no? > > Yes. `make distclean' must leave the build directory as it was before > configure. When `make distcheck' is failing in this test it is > because distclean is not properly doing its job -- in a fresh build > directory `configure ; make ; make distclean' must leave the directory > empty. I know what `make distclean' is supposed to do. Not creating distributable files in the build directory would releave us from cleaning them there. Regards, Pavel Roskin
Re: yaccvpath.test
Hello, Alexandre! > Pavel> It's not Perl. It's a timestamp quantization. > > Oops, I should have read this mail before posting my own patch... I'm applying my patch with few other changes. It appears that we have more than one problem - one of them is that the old file is distributed and another one it that "make distcheck" detects the problem quite late - when it runs "make distclean". I understand that your test case was to demonstrate the first problem. But then "make distcheck" is irrelevant - the problem can be detected already after "make distdir" - we don't even need gzip for that! If you want to add a test for "make distcheck" you are welcome to. However, please comment your test next time, otherwise it takes too much time to understand what you meant to test if something goes wrong. And also please make some "unit testing" of your tests. For example, YACC=bison had no chances to work even when configuring in the source tree, since bison outputs files with different names. Regards, Pavel Roskin ____ --- ChangeLog +++ ChangeLog @@ -1,3 +1,12 @@ +2001-02-27 Pavel Roskin <[EMAIL PROTECTED]> + + * tests/yaccvpath.test: Add a delay to make parse.c really out + of date. Detect the problem earlier, after `make distdir'. Drop + dependency on flex. Always use the `-y' flag for bison. Comment + changes. + + * tests/Makefile.am: Add yaccvpath.test to XFAIL_TESTS. + 2001-03-02 Jens Krüger <[EMAIL PROTECTED]> * depend2.am (?!GENERIC??LIBTOOL?%LTOBJ%): Add `%' to fix typo. --- tests/Makefile.am +++ tests/Makefile.am @@ -2,7 +2,7 @@ AUTOMAKE_OPTIONS = gnits -XFAIL_TESTS = +XFAIL_TESTS = yaccvpath.test TESTS =\ acinclude.test \ aclocal.test \ --- tests/yaccvpath.test +++ tests/yaccvpath.test @@ -1,12 +1,19 @@ #! /bin/sh -# This attempts to `make distcheck' from a separate directory -# (i.e. builddir!=srcdir). Before doing `make distcheck' a parser -# definition is updated in the srcdir in order to check whether the -# archived perser is up-to-date or not. +# This test checks that dependent files are updated before including +# in the distribution. `parse.c' depends on `parce.y'. The later is +# updated so that `parse.c' should be rebuild. Then we are running +# `make' and `make distdir' and check whether the version of `parse.c' +# to be distributed is up to date. . $srcdir/defs || exit 1 +# Fail gracefully if no autoconf. +$needs_autoconf +# Likewise for some other tools. +(gcc -v) > /dev/null 2>&1 || exit 77 +(bison -V) > /dev/null 2>&1 || exit 77 + cat > configure.in << 'END' AC_INIT AC_CONFIG_AUX_DIR([.]) @@ -19,10 +26,11 @@ END cat > Makefile.am << 'END' -bin_PROGRAMS= foo -foo_SOURCES= parse.y foo.c +bin_PROGRAMS = foo +foo_SOURCES = parse.y foo.c END +# Original parser, with `foobar' cat > parse.y << 'END' %{ int yylex () {return 0;} @@ -36,16 +44,8 @@ int main () { return 0; } END -# Fail gracefully if no autoconf. -$needs_autoconf -# Likewise for some other tools. -(gcc -v) > /dev/null 2>&1 || exit 77 -(flex -V) > /dev/null 2>&1 || exit 77 -(bison -V) > /dev/null 2>&1 || exit 77 - -LEX=flex -export LEX -YACC=bison +# We are not checking Autoconf, so we pick $YACC for it. +YACC="bison -y" export YACC # Remove some files installed by defs. @@ -58,15 +58,27 @@ $AUTOCONF $AUTOMAKE -a -bison -y parse.y +$YACC parse.y mv y.tab.c parse.c -cat >> parse.y << 'END' -fubar : 'f' foobar {}; -END - mkdir sub cd sub ../configure + +# A delay is needed to make sure that the new parse.y is indeed newer +# than parse.c, i.e. the they don't have the same timestamp. +sleep 2 + +# New parser, with `fubar' +cat > parse.y << 'END' +%{ +int yylex () {return 0;} +void yyerror (char *s) {} +%} +%% +fubar : 'f' 'o' 'o' 'b' 'a' 'r' {}; +END + $MAKE -$MAKE distcheck +$MAKE distdir +grep fubar foo-0.1/parse.c
Re: yaccvpath.test
Hello, Derek! > > Some unices (including GNU/Linux) are not very precise with respect to the > > timestamps. It's likely that parse.c and the new parse.y are created in > > the same second, so parse.c will appear to be up-to-date. Adding "sleep > > 3" (I have no idea what would be a minimal safe time) before the new > > CVS uses a single second sleep to guarentee timestamps change cross-platform > and we don't see bug reports about it. Only ocassionaly complaints that > scripts which invoke CVS many times take too long. Thanks! Then "touch parse.y" can be moved below "configure", since the later is guaranteed to take at least 1 second (see AM_SANITY_CHECK). Regards, Pavel Roskin
Re: yaccvpath.test
Hello, Alexandre! I'm applying my patch, Ok? > Pavel> Now we have a more interesting error: > > This is *the* error this test is expected to show. Thanks :) The only question remains, whether it's a bug a not. I'm affraid it's a highly debatable topic. I think it's Ok to test for features if there is consensus that it's features and not bugs and vice versa. So I'll outline some questions. If we argee on them - fine, if not, let's not enforce arguments with test cases. 1) "make dist" must ensure that out-of-date generated distributable files (parser.c, Makefile.in etc) are not included in the tarball either by running "make all" or otherwise. Yes or no? 2) "make distcheck" must ensure that out-of-date generated distributable files are not included in the tarball by exiting with non-zero code. Yes or no? 3) Out-of-date generated distributable files should be recreated in the build directory. Always, never, only when no write permissions for srcdir? 4) "make distclean" should attempt to clean generated distributable files that appear in the build directory. Yes or no? Regards, Pavel Roskin
Re: yaccvpath.test
Hello, Alexandre! > Pavel> It fails on RedHat 6.2, but not 7.0. I believe it's a > Pavel> Perl issue. Not sure if I'll have time today to look at > Pavel> this. It's not Perl. It's a timestamp quantization. Some unices (including GNU/Linux) are not very precise with respect to the timestamps. It's likely that parse.c and the new parse.y are created in the same second, so parse.c will appear to be up-to-date. Adding "sleep 3" (I have no idea what would be a minimal safe time) before the new parse.y is created makes the test fail reliably: make[2]: Entering directory `/usr/local/src/am1/tests/testSubDir/sub' bison ../parse.y && mv y.tab.c parse.c ../parse.y contains 1 useless nonterminal and 1 useless rule mv: y.tab.c: No such file or directory make[2]: *** [parse.c] Error 1 Well, another lame error in the few lines of the damned test! Setting YACC=bison is absolutely wrong! It's not going to work this way. Bison creates files with different names by default. If we really don't trust Autoconf to find YACC (probably we shouldn't, since we are testing not Autoconf), let's use YACC="bison -y". By the way, I don't understand why we need LEX. It's absolutely irrelevant to the test. Now we have a more interesting error: make[3]: Leaving directory `/usr/local/src/am1/tests/testSubDir/sub/foo-0.1/=build' Error: files left after distclean make[2]: *** [distcheck] Error 1 make[2]: Leaving directory `/usr/local/src/am1/tests/testSubDir/sub' FAIL: yaccvpath.test The file left after distclean is parse.c in the "=build" directory. Just for reference, here's the patch I applied to yaccvpath.test --- yaccvpath.test +++ yaccvpath.test @@ -40,12 +40,9 @@ $needs_autoconf # Likewise for some other tools. (gcc -v) > /dev/null 2>&1 || exit 77 -(flex -V) > /dev/null 2>&1 || exit 77 (bison -V) > /dev/null 2>&1 || exit 77 -LEX=flex -export LEX -YACC=bison +YACC="bison -y" export YACC # Remove some files installed by defs. @@ -61,6 +58,7 @@ bison -y parse.y mv y.tab.c parse.c +sleep 3 cat >> parse.y << 'END' fubar : 'f' foobar {}; END Regards, Pavel Roskin
Re: yaccvpath.test
Hello, Alexandre! > >> Alexandre claims it fails. > > Yes it should. Then show us how it fails. > Perl? I guess you have found *another* issue :) What I'm trying We'll see when I get home. > to report is just a Makefile issue: $scrdir/parser.c is included > in the distribution insted of ./parser.c. In fact, I believe that you are wrongly assuming this to be a bug. Files that are distributed should be in srcdir. But I don't see that your are testing for that problem. Your test is quite generic - "make distcheck" should pass. Do you expect that one of the version of parse.y is invalid? > >> I always build in a separate directory, never in srcdir. > > Pavel> It should be irrelevant now after since I've added > Pavel> AC_CONFIG_AUX_DIR. > > Isn't this a workaround to an Automake bug? It look so to me: > if install-sh is in current directory, why would Automake prefer > and use ../../install-sh? It's a complicated mix of several bugs and ancient traditions. I believe, the best fix will be to have tests/defs to copy the right install-sh instead of creating an empty file. Regards, Pavel Roskin
Re: yaccvpath.test
Hello, Tom and Alexandre! On 27 Feb 2001, Tom Tromey wrote: > >>>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: > > Pavel> I don't quite understand whether your test is supposed to work > Pavel> or not. It's failing for me (besides the typo in > Pavel> tests/Makefile.am that I've just fixed). > > Alexandre claims it fails. > I've updated it a bit. Now it works for me. > Alexandre, can you investigate the change? It fails on RedHat 6.2, but not 7.0. I believe it's a Perl issue. Not sure if I'll have time today to look at this. > I always build in a separate directory, never in srcdir. It should be irrelevant now after since I've added AC_CONFIG_AUX_DIR. Regards, Pavel Roskin
instdata2.test fails
Hello! I presume that tests not listed in XFAIL_TESTS are supposed to work. instdata2.test doesn't work for me. I'm compiling Automake (from CVS as of Tue Feb 27 15:44:08 UTC 2001) in a separate directory, and the only test that fails is instdata2.test: $ make check TESTS="instdata2.test" VERBOSE=1 make check-TESTS make[1]: Entering directory `/home/proski/src/automake.v0-1/tests' === Running test /home/proski/src/automake.v0/tests/instdata2.test 1,2c1,2 < install-data-am: install-dataDATA install-incldataHEADERS \ < install-pkgdataDATA install-pkgdataSCRIPTS --- > install-data-am: install-binSCRIPTS install-dataDATA \ > install-incldataHEADERS install-localstateDATA \ FAIL: instdata2.test === 1 of 1 tests failed === make[1]: *** [check-TESTS] Error 1 make[1]: Leaving directory `/home/proski/src/automake.v0-1/tests' make: *** [check-am] Error 2 The upper part of diff (after "<") is what is expected to be there. For some reason install-data-am depends on install-binSCRIPTS and other additional targets on my system. The full rule is: install-data-am: install-binSCRIPTS install-dataDATA \ install-incldataHEADERS install-localstateDATA \ install-pkgdataDATA install-pkgdataSCRIPTS install-sbinSCRIPTS \ install-sysconfDATA I'm using RedHat 7.0 with Perl 5.6.0. Regards, Pavel Roskin
yaccvpath.test
Hello, Alexandre! I don't quite understand whether your test is supposed to work or not. It's failing for me (besides the typo in tests/Makefile.am that I've just fixed). I believe there is a convention in Automake that whenever a knowingly failing test is committed, it is added to XFAIL_TESTS, and it's only removed from there when the fix is committed. Maybe you don't know, but yaccvpath.test fails very differently when automake is configured in the source directory and outside it. You probably should add AC_CONFIG_AUX_DIR(.) to the test (see e.g. install2.test), unless I'm missing something. Also please make sure that the test is ignored when bison and yacc are not available. Regards, Pavel Roskin
Re: Question marks in Makefile.in
> Nonetheless, given that we can never be sure to what extend the test > suite exercise Automake, I would include it anyway: better have > automake dying than make. Just imagine > > ?SOME-CONDITION-RARELY-TRUE? %SOME-PARAM-WE-FORGOT%. Ok Regards, Pavel Roskin
Re: Question marks in Makefile.in
Hello, Akim! > > Maybe it's not necessary to check the output since the user is highly > > unlikely to use ?FOO? in Makefile.am. I understand it's an internal > > mechanism for Automake, not exposed to users. > > > > However, an optional check would be appropriate. It could be turned on in > > the testsuite. > > I have not understood. Sure, this test would be enabled only for > Automake's *.am file, and only when outputting these files themselves, > not in Makefile.in. I mean, this check is _probably_ not necessary on a user system, since the users will use well tested versions of Automake. But I don't have a strong opinion. A fast and simple check should not be a big deal. Developers of Automake, however, should always be sure that such variables are not left in the output. > ?AMDEP?@AMDEP@%FPFX%DEPMODE = @%FPFX%DEPMODE@ > > where ? means, automake-time Boolean, %, automake-time variable, @, > configure-time variable. Excellent! Regards, Pavel Roskin
Re: Question marks in Makefile.in
Hello, Akim! > > ?EXEC?insexec-data-am: install-info-am > > ?!EXEC?install-data-am: install-info-am By the way, it will be nice to have a test that actually fails in absense of insexec-data-am or install-data-am. > Still, this bug can be easily detected by automake. But @FOO@ bugs Maybe it's not necessary to check the output since the user is highly unlikely to use ?FOO? in Makefile.am. I understand it's an internal mechanism for Automake, not exposed to users. However, an optional check would be appropriate. It could be turned on in the testsuite. > are harder since we share @ with AC_SUBST. I would really love to > use %FOO% instead in Automake. Tom, what do you think? This would > make it possible for automake to check what it outputs. Are you suggesting AM_SUBST? Regards, Pavel Roskin
FYI: install.am is not in Makefile.am
Hello! The top-level Makefile.am on CVS Automake doesn't know anything about install.am. _ --- ChangeLog +++ ChangeLog @@ -1,3 +1,7 @@ +2001-02-26 Pavel Roskin <[EMAIL PROTECTED]> + + * Makefile.am: Add install.am. + 2001-02-26 Akim Demaille <[EMAIL PROTECTED]> * automake.in (&target_cmp, &dist_cmp): Do not prototype comparing --- Makefile.am +++ Makefile.am @@ -12,7 +12,7 @@ amfiles = check.am clean-hdr.am clean-kr.am clean.am comp-vars.am \ compile.am data-clean.am data.am dejagnu.am depend.am depend2.am \ -distdir.am footer.am header-vars.am header.am \ +distdir.am footer.am header-vars.am header.am install.am \ java-clean.am java.am kr-extra.am library.am libs-clean.am libs.am \ libtool.am lisp-clean.am lisp.am ltlib-clean.am ltlib.am ltlibrary.am \ mans-vars.am mans.am multilib.am program.am progs-clean.am progs.am \ _________ Regards, Pavel Roskin
Question marks in Makefile.in
Hello, Akim! The version 1.272 of the top-level Makefile.in that you submitted today to the Automake CVS contains the following lines: ?EXEC?insexec-data-am: install-info-am ?!EXEC?install-data-am: install-info-am I believe those question marks are supposed to be processed by Automake. They should not appear in Makefile.in. Something must be wrong in your patches. Regards, Pavel Roskin
Re: .PHONY targets are not needed?
Hello, Akim! > Is this only GNU Make, or a general property? > > /tmp % cat Makefile 21:37 remo > all: foo bar > .PHONY: all foo > /tmp % make 21:37 remo > make: *** No rule to make target `bar', needed by `all'. Stop. $ pmake pmake: Don't know how to make target `foo' $ rpm -qa |grep pmake pmake-2.1.34-6 So it's not a general property. But why are you asking whether .PHONY targets are needed? You are declaring a target PHONY without providing a rule for it (foo). It's not what Automake does. The real usefulness on .PHONE if that "all" will be remade even if a file named "all" exists for some reason in the current directory (or in VPATH). Regards, Pavel Roskin
Re: ##-xxx-xxx.patch
Hello, Allan! On Wed, 21 Feb 2001, Allan Clark wrote: > Akim, everyone; I'm rather everyone than Akim, but anyway :-) > Is there I way I can simply get the discussion, without the binary/patch > traffic? I would prefer to receive this kind of thing through an update > from a source-control (ie CVS) than copies from email. It is mostly proposed patches and they are posted here for discussion. But I agree that it may be better to have a separate list. > Should I sign up on a different list? Should [EMAIL PROTECTED] > be formed? It should be [EMAIL PROTECTED] for consistency with Autoconf. By the way, it's not binaries, it's Perl code. Sometimes they look confusingly similar :-) Regards, Pavel Roskin
Re: 50-many-my.patch
Hello, Akim! On Wed, 21 Feb 2001, Akim Demaille wrote: > Index: ChangeLog > from Akim Demaille <[EMAIL PROTECTED]> > > * automake.in: Promote local `my' over `local'. I fully agree with this approch. I believe you should be allowed to checking such patched without approval. But please be careful. I remember that Tom said maybe a year ago that not all `local' can be replaced with `my' - there are cases where the name is used in the subfunctions. So please be careful, and alway run the testsuite before commit. Also it would be nice if you checked on some projects that the makefiles don't change. I see you are doing it with Autoconf. Consider a bigger project for the test (Lesstif should be fine). Note that I'm not asking you to check the correctness of the makefiles (it would be too time-consuming for huge projects), just make sure that they don't change. You have my full support if you do so. Regards, Pavel Roskin
"set -e" in subshell is now reliable
Hello, Akim! You recently applied a patch to tests/target-cflags.test without mentioning it in ChangeLog. Maybe you didn't mean to commit that change? If you did, then two small fixes are needed: 1) You should run ./foo instead /foo 2) bash could not detect it because "set -e" doesn't propagate to the subshell. I only could catch it on FreeBSD 4.0. I think it's better to stay on the safe side and eliminate the subshell. I tried "set -e" in subshell but it didn't work as it should (with bash-1.14.7). ChangeLog: * tests/target-cflags.test: Don't use subshell to configure in subdirectory. Typo fix - run `./foo', not `/foo'. _ --- tests/target-cflags.test +++ tests/target-cflags.test @@ -52,13 +52,14 @@ $AUTOCONF $AUTOMAKE -a mkdir obj -( -cd obj -../configure -$MAKE -/foo -./bar -) + +cd obj +../configure +$MAKE +./foo +./bar +cd .. + ./configure $MAKE ./foo _ Regards, Pavel Roskin
FYI: useless tabs before variable definitions
Hello! When you modify Automake and commit your changes it's often a good idea to run the new automake in the automake working directory and check the difference in Makefile.in. This trick would show you that the variables "host_alias" and others are now preceeded by tabs. This is not good. ChangeLog: * header-vars.am: Remove tabs before variable definitions. __ --- header-vars.am +++ header-vars.am @@ -81,9 +81,9 @@ ## _triplet values? ## FIXME: this should probably use generic %configure_vars method. ## Let's wait until we rely upon traces. -?BUILD?build_alias = @build_alias@ -?BUILD?build_triplet = @build@ -?HOST? host_alias = @host_alias@ -?HOST? host_triplet = @host@ -?TARGET? target_alias = @target_alias@ -?TARGET? target_triplet = @target@ +?BUILD?build_alias = @build_alias@ +?BUILD?build_triplet = @build@ +?HOST?host_alias = @host_alias@ +?HOST?host_triplet = @host@ +?TARGET?target_alias = @target_alias@ +?TARGET?target_triplet = @target@ ______ Regards, Pavel Roskin
Re: PATCH: patsubst support
Hello, Alex! > Here is a new version of the patsubst patch against cvs HEAD. Thanks! Were are getting closer. > + * automake.in (expand_contents): add new function to perform > + the patsubst expansion > + (value_to_list): add support for patsubst style variable > + substitution. > + (read_main_am_file): call expand_contents to output > + variables. > + > + * tests/patsubst.test: add test for patsubst expansion > + > + * tests/patsubst2.test: add test for conditional patsubst > + expansion > + > + * tests/Makefile.am: reference patsubst.test and patsubst2.test Sorry, I'll be pedantic. Capitalize the first word (s/add/Add/). Don't leave blank lines - they are used to distinguish separate commits. Don't omit a full stop. > - ($from = $2) =~ s/(\W)/\\$1/g; > + ($from = $2) =~ s/(\W)/$1/g; I don't understrand this. This change will affect the traditional rules as well. It should probably be a separate patch if it fixes a separate issue. You may even need a test case. > - if ($from) > + if ($from =~ '^([^%]*)%([^%]*)') > { > - grep (s/$from$/$to/, @temp_list); > + # patsubst style substitution > + my ($prefrom, $suffrom, $preto, $sufto); > + $prefrom = $1; > + $suffrom = $2; When I first saw "preto" and "suffrom" I thought it's probably in Latin :-) Bytes are cheap, especially when they don't end up in every Makefile.in for every package. Use suffix_from or whatever is appropriate. ... > + } > + elsif ($from) > + { > + # standard substitution reference style > + grep (s/$from$/$to/, @temp_list); > } what I don't see here is a case for $from containing '%' but not matching our rule. It should be something like: elsif ($from) { # standard substitution reference style if ($from =~ '%') { &am_error ("\`$from' cannot be expanded"); } grep (s/$from$/$to/, @temp_list); } Note that am_error() doesn't stop the execution, but causes automake to exit with code 1. > +sub expand_contents > +{ > +my ($var, $value, $cond) = @_; > +my ($ret) = $value; > + > +if ( $value =~ m/([^%]*)%([^%]*)%/ ) > +{ > + my @curval = &variable_value_as_list ($var, $cond); > + my ( $val ); > + $ret = ''; > + foreach $val ( @curval ) > + { > + $ret .= $val . " "; > + } How about this: join(" ", @curval) Everything else is fine. I'm sorry that I'm keeping bouncing your work, but the Automake code should be of the highest quality. Regards, Pavel Roskin
Re: Testsuite fails
Hello, Tom! > Pavel> AC_CHECK_TOOL([STRIP],[strip]) > > Yes, I wasn't thinking. I've removed this. > > Ideally we'd have some way to tell autoconf, "if this package can be > cross-compiled, then check for a cross `strip' as well". Maybe > there's an ugly way to do this. Actually, I think that Automake is wrong assuming that AC_CHECK_TOOL requires config.{guess,sub}. It's no longer true for the CVS Autoconf. The idea of AC_CHECK_TOOL is that if you are cross-compiling for e.g. i386-aix, then configure should check for i386-aix-strip and for the canonicalized form, i386-ibm-aix-strip. If the canonicalized form cannot be found - no problem, don't check for it. Those who want to cross-compile are supposed to be smarter than normal users - they'll fix it if it fails. Not sure if Autoconf is doing exactly that, but at least configure runs without asking for config.{guess,sub}. A lot of code in Automake was written when Autoconf had no maintainer, so Autoconf tried to compensate for Autoconf's shortcomings. It's time to start getting rid of that code. On the other hand, Autoconf still lacks the ability to add missing files. But this should be fixed in Autoconf, not in Automake. Maybe tracing will help. We probably need a special macro, e.g. AC_REQUIRE_FILE, so that the macros will be able to indicate what files they need. The only question is whether it should be processed by Autoconf, Automake or both. Regards, Pavel Roskin
Testsuite fails
Hello! After the changes committed today the testsuite fails. The first failing test is aclocali.test: $ make check TESTS=aclocali.test VERBOSE=1 make check-TESTS make[1]: Entering directory `/usr/local/src/automake.v0/tests' === Running test ./aclocali.test automake: configure.in: required file `./config.guess' not found automake: configure.in: required file `./config.sub' not found FAIL: aclocali.test I looked at the changes in init.m4 - now AM_INIT_AUTOMAKE calls AM_PROG_INSTALL_STRIP, which ends with: AC_CHECK_TOOL([STRIP],[strip]) AC_CHECK_TOOL requires config.status and config.sub. It's probably not a big deal. As long as Autoconf and Automake develop, they face system specific issues that can most effectively be dealt with when the system name is known. But some people may believe that config.guess is a road to hell - I don't agree with them but I feel uncomfortably that they were not asked (i.e. the problem was not identified because the testsuite failures hadn't been detected) The testsuite is probably easy to fix - maybe it's just the matter of adding "--add-missing" to the definition of AUTOMAKE variable. But what bothers me is the fact that very serious patches were committed without running the testsuite. When I'm asked to comment about a patch I often say - Ok if the testsuite passes. I.e. I don't see anything bad in the patch, but I'm not a shell and not a perl interpreter to check the syntax. However, I believe that the existing testsuite should catch possible problems. Some people are offended by this condition because it's _implied_. But now we have to think how to fix the testsuite that already fails. Regards, Pavel Roskin
Re: PATCH: patsubst support
Hello, Alex! Sorry for another delay. Your patch is very important, but unfortunately I'm have been very busy recently. > Here is an updated patsubst patch against CVS automake. Any patsubst > style variables are now staticly expanded by automake, thus avoiding > make portability problems. We now have a single ChangeLog in the top-level directory. > I have included tests for both the normal and conditional cases of > variable expansion. The test for the conditional case doesn't really test how the pattern is expanded. And for me it's expanded incorrectly: @TEST_TRUE@VAR = @TEST_TRUE@zar doz Note missing ".c" extentions. The first test just fails. > Please consider this for checkin. Only when it's done correctly. Few notes about the implementation. > + (handle_options): add new option "no-expand-patsubst" I don't like adding unsafe options. I cannot imagine any situation when anybody would need it for a legitimate reason. Using patterns with the older versions of Automake is incorrect, so I'm not concerned if we break it. It's better to have the same makefiles for users and developers unless there are really serious reasons for them to be different. But if you insist, the new options should be documented. > + (expand_contents): add new function to perform the patsubst expansion > + (value_to_list): add support for patsubst style variable > + substitution. > + (read_main_am_file): call expand_contents to output > + variables. Add extra call to handle_options, otherwise options > + are set after they have effect. Very dirty. Now we are calling handle_options twice. > +sub expand_contents > +{ > +local ($var, $value, $cond) = @_; We are using "my", not "local" for the new code. Eventually Automake will get rid of "local" variables. > +local ($ret) = $value; > + > +if ( $value =~ m/([^%]*)%([^%]*)%/ ) > +{ > + if ( $expand_patsubst ) > + { > + local @curval = &variable_value_as_list ($var, $cond); Maybe I'm missing something, but I don't see any error protection here. You are working with user input. What if the expression is invalid? > +$AUTOMAKE || exit 1 > + > +grep '^@TEST_TRUE@' Makefile.in || exit 1 > +exit 0 As I said before, this is not a test for pattern expansion. Regards, Pavel Roskin
Re: "all" is no longer PHONY
Hello, Tom! > Pavel> In the Automake CVS the target "all" is not longer PHONY. Is it > Pavel> a bug or an intentional change? If the later, what was the > Pavel> reason? > > Bug. Thanks for the fix! However, "all-am" is still not PHONY. Regards, Pavel Roskin
"all" is no longer PHONY
Hello! In the Automake CVS the target "all" is not longer PHONY. Is it a bug or an intentional change? If the later, what was the reason? If the former, I'll try to find who's "guilty". Regards, Pavel Roskin
Re: automake 1.4d
Hello, John! On Tue, 13 Feb 2001, John Poltorak wrote: > It contains old versions of config.guess and config.sub. I was going to write exactly that! I believe we need something like the "wget-update" target in Automake. Maybe it should even be dist-hook. Regards, Pavel Roskin
Re: AC_CANONICAL_*
Hello, Derek! On Fri, 9 Feb 2001, Derek R. Price wrote: > Why do the AC_CANONICAL_* functions no longer set *_alias? There's a "cvs annotate" and "cvs log" are your friends. Akim did it. But the log message is silent about "FIXME". Akim? I believe it should be safe to remove "dnl". Regards, Pavel Roskin
Re: empty line in compilation rules
Hello, Tom! > I added another test to pr87.test to check for this failure. I have fixed it so that it fails "correctly", not because foo/Makefile.in is tested before being created :-) Regards, Pavel Roskin --- ChangeLog +++ ChangeLog @@ -1,3 +1,7 @@ +2001-02-08 Pavel Roskin <[EMAIL PROTECTED]> + + * tests/pr87.test: Check foo/Makfile.in after it is created. + 2001-02-08 Tom Tromey <[EMAIL PROTECTED]> * tests/pr87.test: Added check for blank line after `.c.o' rule. --- tests/pr87.test +++ tests/pr87.test @@ -38,6 +38,12 @@ rm missing install-sh mkinstalldirs +# We use gcc and not gcc -traditional as the latter fails on some +# Linux boxes (Red Hat 5.1 in particular). +$ACLOCAL \ + && $AUTOCONF \ + && $AUTOMAKE -a || exit 1 + # Regression test for bug where `.c.o:' is followed by blank line. (while read line; do if test "$line" = ".c.o:"; then @@ -49,11 +55,6 @@ fi done) < foo/Makefile.in || exit 1 -# We use gcc and not gcc -traditional as the latter fails on some -# Linux boxes (Red Hat 5.1 in particular). -$ACLOCAL \ - && $AUTOCONF \ - && $AUTOMAKE -a \ - && cd build \ +cd build \ && CC='gcc' ../configure \ - && $MAKE distcheck + && $MAKE distcheck || exit 1
Re: tests/ChangeLog
On 7 Feb 2001, Tom Tromey wrote: > I've long considered it a mistake that tests/ChangeLog exists. I > think it should be merged with the main ChangeLog. > > How about I rename tests/ChangeLog and we start putting entries into > the toplevel ChangeLog? Any objections? No objections. In fact, by having two ChangeLogs GNU Automake "endorses" its users to use this style. This should be fixed. Regards, Pavel Roskin
Re: DIST_COMMON broke
> This area still requires more work. I think I know another case where > it can fail: suppose you do `AC_OUTPUT(subdir/foo)' where there is no > Makefile.am in subdir? Then I think no rule to rebuild subdir/foo > will be generated. I would not call it a "failure" - if Automake doesn't control that directory then it shouldn't care. I don't like rules that rebuild something in a directory other than "." and (in limited situations) $srcdir. Maybe my understanding is too primitive, I don't know. Regards, Pavel Roskin
Re: DIST_COMMON broke
Hello, Tom! > Derek> I've attached a slightly more succinct test for the original > Derek> problem I pointed out (distcommon.test). It's nice as a > Derek> perquisite at least, as it doesn't require autoconf or make... > Derek> I'm not quite sure I understand the second problem you pointed > Derek> out. > > I'm checking this in. I'm sorry, but the bug seems to be yours. The new test fails after automake.in changes from revision 1.848 to 1.849. revision 1.849 date: 2001/02/04 03:27:52; author: tromey; state: Exp; lines: +27 -11 * automake.in (handle_configure): Don't modify variable which aliases list element. Don't push @inputs onto the dist list. Fixes colon7.test. (initialize_per_input) [dist_dirs]: New variable. (handle_dist_worker): Use global dist_dirs. (handle_configure): Set dist_dirs entries at toplevel. In fact it says directly: "Don't push @inputs onto the dist list." Not good. Many programs rely on that. Regards, Pavel Roskin
Re: DIST_COMMON broke
Hello, Derek! > How about this test (distdir2.test): Oops, posted to early. Some sanity checks were missing. > It fails even earlier when it creates an empty archive on "make dist". > This seems to be another bug. Never mind. I just forgot to remove "missing". The new test fails exactly how it should. I'm going to apply it unless you come with something better. Regards, Pavel Roskin Index: tests/ChangeLog --- tests/ChangeLog +++ tests/ChangeLog @@ -1 +1,6 @@ +2001-02-07 Pavel Roskin <[EMAIL PROTECTED]> + + * distdir2.test: New test. + * Makefile.am (XFAIL_TESTS): Add distdir2.test. + 2001-02-04 Tom Tromey <[EMAIL PROTECTED]> Index: tests/Makefile.am --- tests/Makefile.am +++ tests/Makefile.am @@ -2,7 +2,7 @@ AUTOMAKE_OPTIONS = gnits -XFAIL_TESTS = +XFAIL_TESTS = distdir2.test TESTS =\ acinclude.test \ aclocal.test \ Index: tests/distdir2.test --- /dev/null +++ tests/distdir2.test @@ -0,0 +1,44 @@ +#! /bin/sh + +# Make sure that the templates of files that appear in configure.in +# are distributed. + +. $srcdir/defs || exit 1 + +cat > configure.in << 'END' +AC_INIT(foo) +AC_CONFIG_AUX_DIR(.) +AM_INIT_AUTOMAKE(distdir2, 0) +AC_OUTPUT([Makefile foo/Makefile foo/bar]) +END + +cat > Makefile.am <<'END' +SUBDIRS = foo +END + +mkdir foo + +cat > foo/Makefile.am <<'END' +noinst_SCRIPTS = bar +END + +touch foo/bar.in + +# Fail gracefully if no autoconf. +$needs_autoconf + +# Likewise for gcc. +(gcc -v) > /dev/null 2>&1 || exit 0 + +touch README NEWS AUTHORS ChangeLog + +# Remove some files installed by defs. These will be reinstalled by +# automake. +rm -f install-sh missing mkinstalldirs depcomp + +$ACLOCAL || exit 1 +$AUTOCONF || exit 1 +$AUTOMAKE -a || exit 1 +CC=gcc ./configure || exit 1 +$MAKE || exit 1 +$MAKE distcheck || exit 1
Re: DIST_COMMON broke
Hello, Derek! > > > Looks like someone broke the 'make dist' target in the last few days. I also noticed that. > > > Specifically, input files from AC_OUTPUT are no longer being added to > > > DIST_COMMON... Exactly the same problem. > > Here's the patch. > > This doesn't appear to be the correct fix. I'll write the test case > Tom just requested and see if I can't figure out anymore. How about this test (distdir2.test): __ #! /bin/sh # Make sure that the templates of files that appear in configure.in # are distributed. . $srcdir/defs || exit 1 cat > configure.in << 'END' AC_INIT(foo) AC_CONFIG_AUX_DIR(.) AM_INIT_AUTOMAKE(distdir2, 0) AC_OUTPUT([Makefile foo/Makefile foo/bar]) END cat > Makefile.am <<'END' SUBDIRS = foo END mkdir foo cat > foo/Makefile.am <<'END' noinst_SCRIPTS = bar END touch foo/bar.in $ACLOCAL || exit 1 $AUTOCONF || exit 1 $AUTOMAKE -a || exit 1 CC=gcc ./configure || exit 1 $MAKE || exit 1 $MAKE distcheck || exit 1 ______ It fails even earlier when it creates an empty archive on "make dist". This seems to be another bug. Regards, Pavel Roskin
Re: AM_INCLUDE is a bad name.
Hello, Akim! > Under this condition, I will definitely quit the group. I'm OK with > providing reasonable backward compatibility, but I'm tired (to remain > somewhat polite) of wasting my time in details of the past. You are missing the point completely. Nobody is asking _you_ to care about backward compatibility. I know, it's really hard if you want to make radical changes. The point is that we should allow other people (be it maintainers of Libtool or GTK+ or NCurses) to provide macros compatible with more that one version of Autoconf if: 1) They are under pressure to do it. 2) They manage to do it correctly (which may be impossible, but _we_ shouldn't care too much). The alternatives are: 1) ifdef - may be obsoleted in the future by m4_ifdef 2) Providing different macro files for different versions of autoconf - really ugly. 3) Switching everybody to the next version of Autoconf. This is a major headache for the projects as big as GNOME. > I am *not* interested in helping obsolescent users, I'm interested in It is not about you helping obsolescent users. It is about allowing other people help them. I don't want to force any changes against your will. If you don't change you mind I don't want to push this idea. "ifdef" works for me. Regards, Pavel Roskin
Re: AM_INCLUDE is a bad name.
Hello, Tom! > What if instead we decide on a permanent naming scheme for automake > internal variables? Then we can start moving towards that over time, > starting here. > > What if instead we use `_AM_'? Or `_am_'? After another consideration I decided that AM_INCLUDE is not meant to be private since it appears in AC_SUBST. I have applied my patch as is (i.e. AM_INCLUDE -> AMINCLUDE), because it's bad that the testsuite is failing in the middle of a major modifications. I believe that we should move towards "use strict" in automake.in. Although it would catch just few errors, strict typing in large projects (which Automake already is) is usually worth it. Regards, Pavel Roskin
Re: AM_INCLUDE is a bad name.
Hello, Tom! > Pavel> How about renaming AM_INCLUDE to AMINCLUDE everywhere? The > Pavel> patch is attached. It fixes all tests. My approach was too formal. AM_INCLUDE is a variable, but the names of variables shouldn't contain any capital letters. My fault. > What if instead we decide on a permanent naming scheme for automake > internal variables? Then we can start moving towards that over time, > starting here. > > What if instead we use `_AM_'? Or `_am_'? I believe that names beginning with am_ are private. I.e. AM_INCLUDE should become am_include. I believe that user code should not do anything with the names beginning with ac_ and am_. Public names don't have any specific prefix: cross_compiling, SHELL, program_suffix, x_libraries, M4, MISSING etc. It's too late to introduce one. Regards, Pavel Roskin
Re: AM_INCLUDE is a bad name.
> Tom, you should also know you can have a special exception, and tell > autoconf AM_INCLUDE is OK. But I agree with Pavel it looks way too > much like a macro name, in itself it is confusing. As far as I know, it cannot be done without breaking compatibility with Autoconf 2.13. Too bad Autoconf doesn't provide (offically at least) any means for writing macros conditionally for particular versions of Autoconf. This feature may be useful for Automake and other tools working together with Autoconf, as well as for any packages installing m4 files (gettext, GTK+, gnome-libs). I mean something like AC_VERSION_CASE( [<=2.13], [test "$FOO" = yes && tmp=foo; AC_CONFIG_SUBDIRS([$tmp])], [default], [test "$FOO" = yes && AC_CONFIG_SUBDIRS([foo])]) We may do our best, but we cannot guarantee 100% backward compatibility. Regards, Pavel Roskin
AM_INCLUDE is a bad name.
Hello, Tom! I see that you are not using the latest and greatest Autoconf. Names beginning with AM_ are reserved for macros. Autoconf-2.49c will not allow such names in configure. That's why many tests are failing again - AM_INCLUDE is not a good name for a variable. How about renaming AM_INCLUDE to AMINCLUDE everywhere? The patch is attached. It fixes all tests. Regards, Pavel Roskin ___ --- ChangeLog +++ ChangeLog @@ -1,3 +1,10 @@ +2001-02-05 Pavel Roskin <[EMAIL PROTECTED]> + + * automake.in (handle_dependencies): Rename AM_INCLUDE to + AMINCLUDE. + * m4/make.m4 (AM_MAKE_INCLUDE): Likewise. + * tests/exsource.test: Likewise. + 2001-02-05 Akim Demaille <[EMAIL PROTECTED]> * automake.in (handle_texinfo): No longer hard code the clean --- automake.in +++ automake.in @@ -3037,7 +3037,7 @@ $output_rules .= "\n"; foreach $iter (@deplist) { - $output_rules .= "\@AMDEP\@\@AM_INCLUDE\@ " . $iter . "\n"; + $output_rules .= "\@AMDEP\@\@AMINCLUDE\@ " . $iter . "\n"; } $output_rules .= &file_contents ('depend'); --- m4/make.m4 +++ m4/make.m4 @@ -10,15 +10,15 @@ END # If we don't find an include directive, just comment out the code. AC_MSG_CHECKING([for style of include used by $am_make]) -AM_INCLUDE='#' +AMINCLUDE='#' for am_inc in include .include; do echo "$am_inc confinc" > confmf if test "`$am_make -f confmf 2> /dev/null`" = "done"; then - AM_INCLUDE=$am_inc + AMINCLUDE=$am_inc break fi done -AC_SUBST(AM_INCLUDE) -AC_MSG_RESULT($AM_INCLUDE) +AC_SUBST(AMINCLUDE) +AC_MSG_RESULT($AMINCLUDE) rm -f confinc confmf ]) --- tests/exsource.test +++ tests/exsource.test @@ -29,4 +29,4 @@ $AUTOMAKE || exit 1 -grep '@AM_INCLUDE@ .*/xtra\.P' Makefile.in +grep '@AMINCLUDE@ .*/xtra\.P' Makefile.in ___
FYI: Fix for pr87.test and texinfo8.test
Hello! The first line of the "distdir" rule was not removed from handle_dist_worker() but appeared in distdir.am. This resulted in failures in pr87.test and texinfo8.test Also the preceeding comment was copied to distdir.am but wasn't deleted in automake.in. The following patch has been applied: _ --- ChangeLog +++ ChangeLog @@ -1,3 +1,8 @@ +2001-02-04 Pavel Roskin <[EMAIL PROTECTED]> + + * automake.in (handle_dist_worker): Remove a line that is now + in distdir.am. + 2001-02-04 Kevin Ryde <[EMAIL PROTECTED]> * automake.in (handle_configure): Call config.status with empty --- automake.in +++ automake.in @@ -2677,14 +2677,6 @@ $xform .= 's/.*\@DISTDIRS\@.*//g;'; } -# In loop, test for file existence because sometimes a file gets -# included in DISTFILES twice. For example this happens when a -# single source file is used in building more than one program. -# Also, there are situations in which "ln" can fail. For instance -# a file to distribute could actually be a cross-filesystem -# symlink -- this can easily happen if "gettextize" was run on the -# distribution. -$output_rules .= "\t\@for file in \$(DISTFILES); do \\\n"; if ($cygnus_mode) { $xform .= 's/\@CYGNUS\@\t*/\t/g;'; _ Regards, Pavel Roskin
Re: amtraces
> Hm, I'm in favor of having AC_ARG_PROGRAM always run. I see no use in > having only partial support for this option across configures. In > addition, AM_INIT_AUTOMAKE, IIRC, calls it by itself. > > Pavel, Alexandre, any problem with integrating AC_ARG_PROGRAM in AC_INIT? An obvious problem is that if AC_CANONICAL_TARGET is used, it should be before AC_ARG_PROGRAM and after AC_INIT, so there will be no place for it. AC_CANONICAL_TARGET should be optional - not every program is a compiler. Probably a dubious feature about $target being the default program prefix will have to be dropped. Alternatively, AC_CANONICAL_TARGET should implement it if the values set by (the former) AC_ARG_PROGRAM are pristine (i.e. the transform rule is trivial). Regards, Pavel Roskin
Re: New bugs
Hello, Akim! > If would be *wonderful* if someone had the courage to convert > Automake's test suite to Autotest :( It would be wonderful if Autotest supported XFAIL in same way. We have tests that are known to be broken, and tests failing unexpectedly for maintainers. The way Autoconf is handling the issue is not nice. People run the testsuite on Tru64 v5.1 to find a problem with "the Cat in the Hat" that can be reproduced on every system. Regards, Pavel Roskin
Re: FYI: fixing output of aclocal --verbose
> But since it transmits the --verbnse to its slaves and its slaves are > $verbosing on stderr, it should stay in stderr, so that messages > remain in order. A preferable solution for autoreconf, IMHO, but > somewhat more painful that the current status, would be to have > autoreconf redirect the verbose messages of the sub tools to stdout. > > Unfortunately, this would also mean redirect actually error messages > from subtools to stdout, which doesn't sound right. In fact, when I run "autoreconf --verbose" I only want to know what it's running. I can hardly imagine that I'll ever really need the verbose output of all tools in the same time. If I know how exactly autoreconf is running automake, I'll rerun automake with "--verbose". My suggestion is that autoreconf should 1) print what it's calling by default (except the calls to autoconf --trace and others that don't change files). No redirections. 2) don't print what it's calling with --quiet. No redirections. 3) when called with --verbose, propagate it, print what it's calling and redirect all to stderr. This would change the default behavior, but since the output of autoreconf is intended mostly for humans, it shouldn't be an issue. Regards, Pavel Roskin