bug#19615: make dist tarball contains owner/group information from the build system
My situation is even worse. My user ID is so large that "make dist" fails for me: tar: value 3186326 out of uid_t range 0..2097151 tar: Exiting with failure status due to previous errors gtar: value 3186326 out of uid_t range 0..2097151 gtar: Exiting with failure status due to previous errors The fix was promised back in year 2008. I hope we'll see it. In the days of cloud computing, large user ID is an everyday reality. http://comments.gmane.org/gmane.comp.sysutils.automake.bugs/4340 -- Regards, Pavel Roskin
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
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
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
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
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 END AC_INIT([warnopts], [1.0]) === -- 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
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
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: 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 yacc8test on RedHat Linux 72 with bash 2058(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/yacc8test: Add a command between test and cd to work around a bug in bash-205 === --- tests/yacc8test +++ tests/yacc8test -58,7 +58,7 END $AUTOMAKE -a -test -f /ylwrap +test -f /ylwrap || exit 1 cd sub make foo/parse2o === -- 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 EOF 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 21 || exit 77 $ACLOCAL || exit 1 $AUTOMAKE --add-missing || exit 1 $AUTOCONF || exit 1 CC='gcc' ./configure 2error.log test -z `cat error.log` __
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:
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
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: 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
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
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
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
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
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, 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." 12; \
exit 1; \
else :; fi
+## Make sure `rm' is called with `-f'.
+ @if egrep '\rm ([^-]|\-[^f ]*\)' \
+ $(srcdir)/[a-z]*.am $(srcdir)/tests/*.test | \
+ fgrep -v '##'; then \
+ echo "Suspicious 'rm' invocation." 12; \
+ 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: 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: 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
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: 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 21 | 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 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: `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 __
Re: CVS Automake installs noinst_SCRIPTS.
t; $(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
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 21 || exit 77
+(bison -V) /dev/null 21 || 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 21 || exit 77
-(flex -V) /dev/null 21 || exit 77
-(bison -V) /dev/null 21 || 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, 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
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
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
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 21 || exit 77
-(flex -V) /dev/null 21 || exit 77
(bison -V) /dev/null 21 || 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
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
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
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
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
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
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: ##-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: 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: 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: 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: 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
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: 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: 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: 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
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: 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
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
___
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
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
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: FYI: fixing output of aclocal --verbose
Hello, Akim! Pavel Hello! Aclocal didn't follow the GNU standard for the output Pavel of non-interactive programs. Now all messages printed by Pavel "aclocal --verbose" will start with "aclocal: " to make it Pavel easier to find them in the autoreconf output. While you're at it, I'd like to say that it is not right to display `aclocal:', it should be basename $0. Not that automake and aclocal are often installed under some other name, but... Another related question before I go ahead and enforce a single standard. Should versobe messages go to stdout or stderr? Automake uses stdout, while all other auto* and aclocal use stderr. 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
Re: Perl Bug?
Hello, Akim! +print STDERR "= @_\n"; +print STDERR "== $_\n"; I disagree with this style of programming. GNU standard says that the program name should start with the name of the program followed by the colon. Such patches are sometimes good for debugging, but usually only for the person who added them. Generic puprose debugging interface should at least respect "--verbose" and prepend "automake:" to all messages. What we already have in CVS is unacceptable: $ grep STDERR automake.in print STDERR "automake: programming error: @_\n"; print STDERR "traces: discovered $source\n"; print STDERR "traces: discovered AC_SUBST($args[0])\n"; print STDERR "Pushing $dependees into $_\n"; #print STDERR "result_vars: $result_vars\n"; #print STDERR "result_rules: $result_rules\n"; I believe that all those lines should be removed with the exception of the "programming error". Regards, Pavel Roskin
FYI: Minor fix for the testsuite
Hello! Please don't use "sh -x" in the tests - otherwise they will be too verbose even in VERBOSE is not set. _ --- makevars.test +++ makevars.test @@ -1,4 +1,4 @@ -#! /bin/sh -x +#! /bin/sh # Test to make sure that automake includes the needed variables, # but not too many. --- ChangeLog +++ ChangeLog @@ -1,3 +1,7 @@ +2001-01-25 Pavel Roskin [EMAIL PROTECTED] + + * makevars.test: Disable shell tracing. + 2001-01-25 Akim Demaille [EMAIL PROTECTED] * makevars.test: New. _ Regards, Pavel Roskin
Re: PATCH: patsubst support
Hello!
Trying to catch up with the mailing lists :-)
I'm surprised that this patch has not been applied since October. I
believe it's very valuable. I even considered doing it myself.
b) default static expansion to off, avoids surprising anyone depending
on dynamic expansion by make, retains the same non-portable
default behavour as current CVS.
# Makefile.in fragment
FOO = foo bar
BAR = ${FOO:%=%.c}
This would be wrong. This is only acceptable in the developer's
environment, i.e. not in the makefiles created by "make dist". But I see
no serious reason to generate different makefiles in this case.
Regards,
Pavel Roskin
Re: AM_CONDITIONAL
Hello, Anna! AM_CONDITIONAL(ARCI,[test x"$BLD" = xarci]) AM_CONDITIONAL(APB,[test x"$BLD" = xapb]) from automake I get: Makefile.am:5: ARCI does not appear in AM_CONDITIONAL That's weird. Could you please send me (not to the list!) your configure.in? Regards, Pavel Roskin
FYI: AM_PROG_REGEX was broken
Hello!
I have checked (manually) all Automake *.m4 files for underquoting.
AM_PROG_REGEX was actually broken. Now it's fixed.
Maybe I'll run the Automake macros through the Autoconf testsuite some
day.
I also scanned for other cases where quoting is desired. Whenever you have
a free-form message somebody can add a comma and break it, so I added
quotes in all AC_MSG_* for all agruments other than single words.
Regards,
Pavel Roskin
_
Index: m4/ccstdc.m4
--- m4/ccstdc.m4Wed Aug 2 04:59:16 2000
+++ m4/ccstdc.m4Thu Nov 23 20:50:35 2000
@@ -30,7 +30,7 @@
dnl FIXME: can't do this because then AC_AIX won't work due to a
dnl circular dependency.
dnl AC_BEFORE([$0], [AC_PROG_CPP])
-AC_MSG_CHECKING(for ${CC-cc} option to accept ANSI C)
+AC_MSG_CHECKING([for ${CC-cc} option to accept ANSI C])
AC_CACHE_VAL(am_cv_prog_cc_stdc,
[am_cv_prog_cc_stdc=no
ac_save_CC="$CC"
@@ -83,7 +83,7 @@
if test -z "$am_cv_prog_cc_stdc"; then
AC_MSG_RESULT([none needed])
else
- AC_MSG_RESULT($am_cv_prog_cc_stdc)
+ AC_MSG_RESULT([$am_cv_prog_cc_stdc])
fi
case "x$am_cv_prog_cc_stdc" in
x|xno) ;;
Index: m4/dmalloc.m4
--- m4/dmalloc.m4 Wed Aug 2 04:59:16 2000
+++ m4/dmalloc.m4 Thu Nov 23 20:51:46 2000
@@ -6,7 +6,7 @@
# serial 1
AC_DEFUN([AM_WITH_DMALLOC],
-[AC_MSG_CHECKING(if malloc debugging is wanted)
+[AC_MSG_CHECKING([if malloc debugging is wanted])
AC_ARG_WITH(dmalloc,
[ --with-dmalloc use dmalloc, as in
http://www.dmalloc.com/dmalloc.tar.gz],
Index: m4/lispdir.m4
--- m4/lispdir.m4 Wed Aug 2 04:59:16 2000
+++ m4/lispdir.m4 Thu Nov 23 20:52:13 2000
@@ -11,7 +11,7 @@
[ --with-lispdirOverride the default lisp directory ],
[ lispdir="$withval"
AC_MSG_CHECKING([where .elc files should go])
-AC_MSG_RESULT($lispdir)],
+AC_MSG_RESULT([$lispdir])],
[
# If set to t, that means we are running in a shell under Emacs.
# If you have an Emacs named "t", then use the full path.
Index: m4/maintainer.m4
--- m4/maintainer.m4Wed Aug 2 04:59:16 2000
+++ m4/maintainer.m4Thu Nov 23 20:52:48 2000
@@ -11,8 +11,8 @@
(and sometimes confusing) to the casual installer],
USE_MAINTAINER_MODE=$enableval,
USE_MAINTAINER_MODE=no)
- AC_MSG_RESULT($USE_MAINTAINER_MODE)
- AM_CONDITIONAL(MAINTAINER_MODE, test $USE_MAINTAINER_MODE = yes)
+ AC_MSG_RESULT([$USE_MAINTAINER_MODE])
+ AM_CONDITIONAL(MAINTAINER_MODE, [test $USE_MAINTAINER_MODE = yes])
MAINT=$MAINTAINER_MODE_TRUE
AC_SUBST(MAINT)dnl
]
Index: m4/multi.m4
--- m4/multi.m4 Sat Aug 26 16:52:57 2000
+++ m4/multi.m4 Thu Nov 23 20:53:03 2000
@@ -8,7 +8,7 @@
[case "${enableval}" in
yes) multilib=yes ;;
no) multilib=no ;;
- *) AC_MSG_ERROR(bad value ${enableval} for multilib option) ;;
+ *) AC_MSG_ERROR([bad value ${enableval} for multilib option]) ;;
esac], [multilib=yes])
# We may get other options which we are undocumented:
Index: m4/python.m4
--- m4/python.m4Wed Aug 2 04:59:16 2000
+++ m4/python.m4Thu Nov 23 20:53:24 2000
@@ -99,5 +99,5 @@
dnl All done.
- AC_MSG_RESULT(looks good)
+ AC_MSG_RESULT([looks good])
])
Index: m4/regex.m4
--- m4/regex.m4 Wed Aug 2 04:59:16 2000
+++ m4/regex.m4 Thu Nov 23 20:46:52 2000
@@ -15,7 +15,7 @@
# will result in a smaller executable file.
AC_DEFUN([AM_WITH_REGEX],
-[AC_MSG_CHECKING(which of GNU rx or gawk's regex is wanted)
+[AC_MSG_CHECKING([which of GNU rx or gawk's regex is wanted])
AC_ARG_WITH(regex,
[ --without-regex use GNU rx in lieu of gawk's regex for matching],
[test "$withval" = yes am_with_regex=1],
@@ -24,8 +24,8 @@
AC_MSG_RESULT(regex)
AC_DEFINE(WITH_REGEX,1,[Define if using GNU regex])
AC_CACHE_CHECK([for GNU regex in libc], am_cv_gnu_regex,
-AC_TRY_LINK([], [extern int re_max_failures; re_max_failures = 1],
- am_cv_gnu_regex=yes, am_cv_gnu_regex=no))
+[AC_TRY_LINK([], [extern int re_max_failures; re_max_failures = 1],
+ am_cv_gnu_regex=yes, am_cv_gnu_regex=no)])
if test $am_cv_gnu_regex = no; then
LIBOBJS="$LIBOBJS regex.$ac_objext"
fi
Index: m4/strtod.m4
--- m4/strtod.m4Mon Oct 16 05:01:36 2000
+++ m4/strtod.m4Thu Nov 23 20:54:09 2000
@@ -63,7 +63,7 @@
AC_CHECK_FUNCS(pow)
if test $ac_cv_func_pow = no; then
AC_CHECK_LIB(m, pow, [am_cv_func_strtod_needs_libm=yes],
-[AC_MSG_WARN(can't find library containing definition of pow)])
+[AC_MSG_WARN([can't find library containing definition of pow])])
fi
fi
])
_
Re: Attempting to unit test
Hello, Tim! On Thu, 16 Nov 2000, Tim Heath wrote: I have added the following lines to a Makefile.am: check_PROGRAMS = test_program test_program_SOURCES = test.C You have discovered a bug in Automake. It still exists in the current CVS version. Don't start lines in Makefile.am with spaces. Automake will not recognize them, neither will it warn you. Regards, Pavel Roskin
Re: Fix for script magic.
Hello, François! From Autoconf documentation: If you omit the space before the path, then 4.2BSD based systems (such as Sequent DYNIX) will ignore the line, because they interpret `#! /' as a 4-byte magic number. Let's remove that comment, as well as all those useless spaces. I would rather keep the legend alive :-) Better safe than sorry. Regards, Pavel Roskin
Re: One more fix for ash-0.2 braindamage
Hello! ChangeLog: * m4/init.m4 (AM_INIT_AUTOMAKE): Don't rely on variable assignments changing $? - it' broken in ash-0.2. * m4/missing.m4 (AM_MISSING_HAS_RUN): Likewise. I saw no objections, so I applied it. One of the buggiest shells should now work better. Regards, Pavel Roskin
Re: avoiding target $(srcdir)/Makefile.in
Hello, John! The last person who asked about this alleged that there will be problems on systems lacking Automake, but couldn't give a real example. I meant, that person expected problems if Makefile.am are included. if these targets are in the Makefile.in, but i do not include aclocal.m4, Makefile.am, or configure.in in the distribution, then make fails. for example: roome [3414] ls CHANGES README cloginrc.sample config.status mkinstalldirs MakefileTodoconfig.cacheconfigure util Makefile.in bin config.log install-sh roome [3415] make make: *** No rule to make target `Makefile.am', needed by `Makefile.in'. Stop. You should include Makefile.am. This is what "make dist" does. If you don't use "make dist" to create the distribution you are going to have problems. Unfortunately, the Automake documentation doesn't emphasize this fact. It is also recommended to run "make distcheck" to make sure that the distribution is complete and functional. Regards, Pavel Roskin
Re: PATCH: strip comments while scanning for macro dependencies
Hello, Alexandre! aclocal is stripping comment lines from configure.in, but not from other files. Hence it can detect wrong dependencies and output useless functions in aclocal.m4. The patch is Ok. Can anybody check it in? Regards, Pavel Roskin
Re: RFC: Default output destination
Hello, Jim and others! Is it that behavior documented? If so, then it's probably not reasonable to change it. I've Cc'd the automake list, because some of automake's rules use bison through $(YACC) -- though I'll bet they all use it in yacc-compatible mode. Yes, Automake currently used bison in Automake-compatible mode, but it would be fair for Automake to switch to the native mode as long as the processed files are distributed and "missing" emulates bison. In any case, the makefiles should specify the output file explicitly instead of relying on weird defaults. | src: | total 32 | -rw-r--r--1 akim lrde27553 oct 2 16:31 calc.tab.c | -rw-r--r--1 akim lrde 3335 oct 2 16:31 calc.y This is not _that_ ugly as it seems - with Automake you want to put sources where they belong - to the source directory. Regards, Pavel Roskin
Re: RFC: Default output destination
Hello, Akim! which agrees with this behavior. The question is then: did the author think about file_name=dir_part/base_part? (And BTW, why the heck is there this `tab' part?) To avoid overriding calc.c if it's a separate source file. /tmp % ls src *tab* -l nostromo Err 1 -rw-r--r--1 akim lrde27517 oct 2 17:38 y.tab.c src: total 4 -rw-r--r--1 akim lrde 3335 oct 2 16:31 calc.y I.e., the output goes to the current directory! | In any case, the makefiles should specify the output file explicitly | instead of relying on weird defaults. This is not possible simply with Yacc/Bison which (can) generates many files (*.output, *.h...). But automake doesn't need all those files - it only needs the parcer. | This is not _that_ ugly as it seems - with Automake you want to put | sources where they belong - to the source directory. The difference source/build you are referring to is based on Automake concepts. They have no sense at all for tools such as bison or gcc etc. They have input and output. I do not want them to try to grasp source/build. I want them to behave uniformly: output *here*. I realize that. It's unfortunate that the native mode of Bison behaves in a less uniform way than the yacc mode. I agree with your point. Bison maintainters may want to fix it along with the documentation. Regards, Pavel Roskin
Re: [Automake] Making a Distribution
Hello, Tom! From my project build directory I would like to use "make dist" and have ALL .am files removed from the distribution package (which I can do by using the target "dist-hook"), but I can't figure out how to automatically eliminate all dependence on "automake" in the "Makefile.in"s. Try placing AM_MAINTAINER_MODE into configure.in. The dependencies will be commented out unless --enable-maintainer-mode is specified to configure. But why do you want to remove .am files? Regards, Pavel Roskin ___ Automake mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/automake
Re: gmake vs. ucb make and SUBDIRS
Hello, Linus! After running aclocal; autoconf; automake -a all seems to be working fine except for ONE thing: running UCB/BSD Make at top level generates the following error: cc@e316:~/src/yawm/yawm-0.0.1-a5% make clean *** Error code 1 In my very humble opinion "make clean" is luxury. It is not essencial to compile and install software. If you want more, use GNU make. This is not to say that the problem should not be fixed if there is a good way to do it. Regards, Pavel Roskin
Re: FW: shall `make uninstall' remove directories?
Hello, David! Therefore, I think I'd suggest, as "make install" has a call to "mkinstalldirs" before the loop to install files, perhaps "make uninstall" should have a call to "mkuninstalldirs" after the loop to remove files. The "mkuninstalldirs" script can handle the cleanup of supposedly dead directories (including having environment variables and/or options that would allow sysadmins/packagers to decide how much they want to clean up). As "mkinsalldirs" is packaged with automake, so could "mkuninstalldirs". Even empty directories do contain information. They have permissions and ownership. Who is to blame if mkuninstalldirs removes /usr/local/share "for you" and then somebody recreates this directory without giving you write access? While setting default permissions on the newly created directories seems reasonable (you can adjust them later) this may not apply to deleting directories. Regards, Pavel Roskin
Re: shall `make uninstall' remove directories?
Hello, Tom! I think we should not introduce more utilities. We have way too many already. How about reimplementing this as a patch to "missing"? Then we can do "missing rmdir -p". Having AM_INIT_AUTOMAKE look for "rmdir -p" would also be appropriate... Let's make "missing" handle "mkdir -p" to begin with. Maybe install-sh could be wrapped into missing as well. I still insist that no directories should be removed by "make uninstall" unless they defininely belong to the package being uninstalled. So please no "rmdir -p". Both "make install" and "make uninstall" are often run by root. I don't want to figure out why /usr/local/man/man8 is not writeable by my group whereas /usr/local/man/man7 is. Regards, Pavel Roskin
Re: shall `make uninstall' remove directories?
Hello, Peter!
That's not quite it either. If I install something into
/opt/foo-0.99/{bin,lib,include} and then it only removes the bin, lib, and
include parts, then it's arguably being less than helpful.
IMHO you install something into /opt/foo-0.99 it's because you don't trust
your packaging system and want to remove things manually when you need to.
/opt is not very popular on systems with good package management.
Pavel Roskin
Re: shall `make uninstall' remove directories?
Hello! a) always remove the directories b) just remove the directories that were created during `make install' c) remove the last level of directory if it's empty d) remove all the levels that are empty e) remove only the directories specific to the package (pkgdatadir, pkglibdir, pkgincludedir) and only if they are empty. I wouldn't bother removing e.g. /usr/local/share - chances are that it will be reused some day. But removing /usr/local/share/foo is a good thing - it indicates that "foo" is no longer installed. Regards, Pavel Roskin
Re: adding -fsigned-char to CFLAGS
Hello, Jeff! Is there a way to add -fsigned-char to the gcc flags on systems with unsigned char types? I know I can detect that with autoconf, but I don't want to change the code I'm compiling. If the code assumes "char" == "signed char" the code is broken. I've started compiling on AIX, but find that I need to edit the Makefile, or always pass -fsigned-char even on platforms that don't need it. The latter works, but seems ugly. It is not uglier that the code you are compiling. In fact, I would prefer to specify -fsigned-char on all platforms if the code assumes signedness of char. No need to test anything in Autoconf. Regards, Pavel Roskin
Re: bcc55 support ?
Hello! Is automake going to support bcc55 ? Or is there a way to create the Makefile for Win$$ + bcc55 from Makefile.am ? Chances are that it will work. I even remember me compiling GNU Indent with Borland C++. However, Borland's native make may have problems. I recommend you using GNU Make. Pavel Roskin
