Re: Error because README is missing
Andreas == Andreas Schwab [EMAIL PROTECTED] writes: Untested code ahead. m4_syscmd([test -f build.sh.in])dnl m4_if(m4_sysval, 0, [AC_CONFIG_FILES(build.sh)]) Bad idea: side effects are incompatible with the (autom4te) cache. If the environment changes but not the sources of configure, it won't be regenerated. Similarly with what Automake needs to trace.
Re: RFC for new FAQ entry: Flag Variables Ordering
Hello, On Tue, Nov 30, 2004 at 07:02:22AM -0800, Bruce Korb wrote: would make sense to add AM_LDADD as a synonym for LDADD purely for that sounds weird. I have an alternative proposal: Automake could watch for variables named AM_* and if it doesn't recognize them, it could issue a warning. This shouldn't annouy anyone, AM_ os kind of reserved prefix in Automake. Just my 1/256 pound. Have a nice day, Stepan
svn copy conflicts with autotools ?
Hi all, Here is the description of a problem met with subversion and autotools. If anybody has a clean solution, let me/us know: 1) I have a project using the autotools for the environment management. 2) The project compiles without any problem in the 'trunk' directory. 3) I have set up a tag with 'svn copy' so that the tagged version is the exact copy of the version in the 'trunk' directory. 4) Another user gets the tagged version with a 'svn co' and runs 'configure' on it. And now ... The problem is that all the dates of the checked out files have been modified, and when running 'make', the first thing run is 'autoconf' and 'automake', thus modifying source directory files (configure, ...). It was even worst in our case, as the autotools installed on the machine were too old and 'make' stopped without having built anything :-( :-( The result is that checking out a tagged version may lead to an unusable source tree (at least a tree needing some source file modifications). This is the reason why I don't think it is a good thing that the subversion philosophy of timestamps conflicts with autotools one. I am looking for a solution that would allow a checkout to avoid rebuilding source files when not necessary. Timestamps need to be preserved somewhat, and I think that the way subversion manages currently timestamps should be coherent with autotools (or autotools should be modified to handle subversion philosophy), and in particular when doing a 'svn copy'. Thanks for your comments (and your solutions), Eric PAIRE
Re: svn copy conflicts with autotools ?
Eric PAIRE wrote: The problem is that all the dates of the checked out files have been modified, and when running 'make', the first thing run is 'autoconf' and 'automake', thus modifying source directory files (configure, ...). You seem to keep generated files like Makefile and configure in the repository. We follow a different approach; no generated files are versioned, not even auxiliary scripts. A developer who wants to compile from repository should have the correct autotoolset version and run autoreconf -ifs and configure first. This is what a svn:ignore looks like for a typical top_srcdir: autom4te.cache build Makefile.in configure aclocal.m4 config.h.in aux Note that we usually build from the build subdirectory, not directly from top_srcdir, and that auxiliary files like config.guess are kept in aux. If a developer wants to compile without using autotools, he should use a distribution tarball (generated by make dist), not the subversion sources. It works :) -- Leonardo Boiko signature.asc Description: OpenPGP digital signature
Re: svn copy conflicts with autotools ?
Hi, On Wed, Dec 01, 2004 at 11:24:33AM -0200, Henrique de Moraes Holschuh wrote: On Wed, 01 Dec 2004, Stepan Kasal wrote: I learned from that text how can autotools and CVS/svn combined. Though I personally obey the rule ``no generated files in the RCS'', I seriously considered the other alternatives because of that text. I will read it, I am curious about what it says that could have such a strong effect on you. Maybe it can change my mind about the issue (but I doubt it)... No, it didn't have _strong_ effect. I just happened to learn about ``CVS in practice'' from that. So perhaps we should suggest that the text pushes the rule ``no generated files in the RCS'' more strongly. Yours, Stepan
Re: svn copy conflicts with autotools ?
On Wed, 01 Dec 2004, Eric PAIRE wrote: 3) I have set up a tag with 'svn copy' so that the tagged version is the exact copy of the version in the 'trunk' directory. 4) Another user gets the tagged version with a 'svn co' and runs 'configure' on it. And now ... As it was once so eloquently explained to me by a senior Debian developer when I asked exactly the same question (but for CVS, since Subversion didn't exist yet): If you're doing that, you're weird. Go away. The translation for that would be: Why the heck are you keeping auto-generated files in a RCS system? Get them out of there, they do NOT belong in the repository! Add a run-this-on-checkout script and proper rules to the makefiles to run the autotools sequence if the autotools files are not yet available. As for a bad autotools setup on the build system, well, document properly what the build system has to have installed for the development versions. Anyone doing development has to be at least capable of a proper build system setup, no? When you generate a release, run autotools before you make a tar.bz2/tar.gz/.cab/whatever file that you're going to distribute. This way, all the autotools scripts are already built and have correct timestamps inside the distribution archive. Normal users won't need to bother with autotools configs, then, unless they muck with Makefile.am, configure.in or something else like that. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: svn copy conflicts with autotools ?
On Wed, 01 Dec 2004, Stepan Kasal wrote: On Wed, Dec 01, 2004 at 10:13:45AM -0200, Henrique de Moraes Holschuh wrote: If you're doing that, you're weird. Go away. The translation for that would be: Why the heck are you keeping auto-generated files in a RCS system? Get them out of there, they do NOT belong in the repository! if you are that firm about the issue, you might try to convince Bruno to fix the node ``Files under CVS'' in the gettext manual. Hmm... just to make things clear, the weird thing was told TO me, not by me. It just happens that I think the person who said it was actually right on the issue (even if HE is the weird one IMHO). At least for CVS, it has been a major help in my experience to never register any autogenerated files on version control. Although I *do* keep history of all releases, so you could say I have some sort of version control of everything (including all autogenerated files) as far as released tarballs go. I learned from that text how can autotools and CVS/svn combined. Though I personally obey the rule ``no generated files in the RCS'', I seriously considered the other alternatives because of that text. I will read it, I am curious about what it says that could have such a strong effect on you. Maybe it can change my mind about the issue (but I doubt it)... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: svn copy conflicts with autotools ?
Henrique de Moraes Holschuh wrote: I will read it, I am curious about what it says that could have such a strong effect on you. Maybe it can change my mind about the issue (but I doubt it)... OTOH I was convinced _not_ to keep autogenerated files in subversion thanks to Henrique's README.Debian for the autotools-dev Debian package, and that made my life better. I recommend it for anyone interested in this issue. Thank you, Henrique. -- Leonardo Boiko signature.asc Description: OpenPGP digital signature
Re: svn copy conflicts with autotools ?
Hi, On Wed, Dec 01, 2004 at 10:15:12AM -0400, Leonardo Boiko wrote: Henrique de Moraes Holschuh wrote: Maybe one of the automake targets do a full cleanup, I never tried to track that down. I never needed it. Doesn't make distclean do that? But I too never needed it... no. make distclean should give you the same tree as when the tarball was unpacked. make maintainer-clean deletes a bit more than distclean, but it still leaves Makefile.in, ./configure, etc. Even after maintainer clean, you don't need to run more than ./configure make to build the package. I think autotools shouldn't even try to support the ``full cleanup''. What if the ./autogen.sh (or ./bootstrap) has imported ``config.guess'', gnulib modules, or whatever? Automake, autopoint, autoheader could remove the files they generate, but I doubt its worth the trouble. Exporting a fresh tree seems much safer. Regards, Stepan Kasal
Re: troubles with conditional install using automake
Stepan Kasal [EMAIL PROTECTED] writes: Hi, while I am not able to address your main problem, I'd like to address one misunderstanding of the make language: On Wed, Dec 01, 2004 at 03:29:10PM +0100, Guillaume Rousse wrote: initrd_SCRIPTS is defined to $(INITRD) at the beginning of the Makefile, while INITRD is defined at the end of the Makefile, with other conditional variables, and thus appears empty when it is evaluated. No, make doesn't work this way; consider the makefile: A = $(BB) e: echo $(A) BB=x Then ``make'' runs ``echo x'' But when $(A) appears on the dependency list of e, for example, it will be expanded already while the makefile is being read in. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: svn copy conflicts with autotools ?
Stepan == Stepan Kasal [EMAIL PROTECTED] writes: Stepan Hello Henrique, Stepan On Wed, Dec 01, 2004 at 10:13:45AM -0200, Henrique de Moraes Holschuh wrote: If you're doing that, you're weird. Go away. The translation for that would be: Why the heck are you keeping auto-generated files in a RCS system? Get them out of there, they do NOT belong in the repository! Stepan if you are that firm about the issue, you might try to Stepan convince Bruno to fix the node ``Files under CVS'' in Stepan the gettext manual. Speaking of manuals, the FAQ section of the Automake manual also have a node called CVS and listing pros, cons, and workarounds. -- Alexandre Duret-Lutz
Re: troubles with conditional install using automake
Guillaume == Guillaume Rousse [EMAIL PROTECTED] writes: [...] Guillaume In this situation, I have an installation target for Guillaume initrd scripts in generated Makefile, using Guillaume $(initrd_SCRIPTS) as dependency. However, Guillaume initrd_SCRIPTS is defined to $(INITRD) at the Guillaume beginning of the Makefile, while INITRD is defined Guillaume at the end of the Makefile, with other conditional Guillaume variables, and thus appears empty when it is Guillaume evaluated. What you describes are two bugs that were present in old versions of Automake. Please look at the Automake version number at the top of the generated Makefile you mentioned. I believe you are not using Automake 1.8 as you think (it probably is Automake 1.4). [...] Guillaume BTW, I'm using autoconf 2.53 and automake 1.8 Unlikely: Automake 1.8 requires Autoconf 2.58 or greater. -- Alexandre Duret-Lutz
Re: Support for precompiled C++ headers
On Wednesday 01 December 2004 1:30 am, Dale E. Martin wrote: Are there short-term plans to facilitate the generation and use of GCC's precompiled headers? Can anyone point me to a C++ project that is working with precompiled headers and that is doing it with the currently available versions of automake and autoconf? Many thanks in advance, I've been wondering about this as well. Anyone have an answer? I add myself to the list of users wanting to know about :)) cya, Christian Parpart. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 00:24:21 up 33 days, 16:54, 0 users, load average: 0.47, 0.50, 0.53 pgpuE1960YQ0w.pgp Description: PGP signature
Re: Support for precompiled C++ headers
On Thu, 2 Dec 2004 00:25:48 +0100, Christian Parpart [EMAIL PROTECTED] said: On Wednesday 01 December 2004 1:30 am, Dale E. Martin wrote: Are there short-term plans to facilitate the generation and use of GCC's precompiled headers? Can anyone point me to a C++ project that is working with precompiled headers and that is doing it with the currently available versions of automake and autoconf? Many thanks in advance, I've been wondering about this as well. Anyone have an answer? I add myself to the list of users wanting to know about :)) me too.
Re: Support for precompiled C++ headers
Roberto == Roberto Bagnara [EMAIL PROTECTED] writes: Roberto Can anyone point me to a C++ project that is working with Roberto precompiled headers and that is doing it with the currently Roberto available versions of automake and autoconf? From the gcjx project on sourceforge: BUILT_SOURCES = [...] typedefs.hh.gch headers = [...] ## FIXME: need a better way to convince libtool to let us do this. typedefs.hh.gch: $(headers) -rm -f typedefs.hh.gch $(CXXCOMPILE) -fPIC -DPIC -x c++-header -o typedefs.hh.gch $(srcdir)/typedefs.hh As you can see I had to hack around libtool. I didn't try a more direct approach, perhaps it would have worked. Also, I always build this project with --disable-static. Tom
Re: svn copy conflicts with autotools ?
Hello Gary, Gary Thomas wrote: Bonjour, Eric :-) On Wed, 2004-12-01 at 04:38, Eric PAIRE wrote: Hi all, Here is the description of a problem met with subversion and autotools. If anybody has a clean solution, let me/us know: 1) I have a project using the autotools for the environment management. 2) The project compiles without any problem in the 'trunk' directory. 3) I have set up a tag with 'svn copy' so that the tagged version is the exact copy of the version in the 'trunk' directory. 4) Another user gets the tagged version with a 'svn co' and runs 'configure' on it. And now ... The problem is that all the dates of the checked out files have been modified, and when running 'make', the first thing run is 'autoconf' and 'automake', thus modifying source directory files (configure, ...). It was even worst in our case, as the autotools installed on the machine were too old and 'make' stopped without having built anything :-( :-( The result is that checking out a tagged version may lead to an unusable source tree (at least a tree needing some source file modifications). This is the reason why I don't think it is a good thing that the subversion philosophy of timestamps conflicts with autotools one. I am looking for a solution that would allow a checkout to avoid rebuilding source files when not necessary. Timestamps need to be preserved somewhat, and I think that the way subversion manages currently timestamps should be coherent with autotools (or autotools should be modified to handle subversion philosophy), and in particular when doing a 'svn copy'. Thanks for your comments (and your solutions), Eric PAIRE Doesn't setting use-commit-times = yes in your local configuration file (~/.subversion/config) solve this? The files will have the timestamp of when you committed them last when you check them out. Thus, you set them up and commit them to the trunk. All is well with the auto-tools. Then copy to your branch/tag. When you check them out you'll get the same timestamp if as when you committed them if you have this option set. Unfortunately, I tried this feature, and it does not solve easily my particular problem : I need to run multiple 'svn commmit' in order to respect modification time of all the tools generated which means multiple 'svn copy' in the right order when tagging a version (a real pain for doing a simple tag :-( For now, the best existing solution is to not commit autotools generated files under source control (which makes sense), and to regenerate them inside a 'svn export' tree. But what keeps on puzzling me with this solution is that you need to modify the source tree of what you 'svn co' in order to be able to use the package delivered. Probably the right solution would be to modify the autotools to only get in the source tree a generic 'configure' able to generate at the very beginning all autotools files in the object tree without having to modify anything in the source tree. It remains clear that autotools and subversion are somewhat in conflict that should be clearly fixed by both sides, saying what is the solution that is jointly recommended. Best regards, Eric
