Re: Patch proposal: Add --clean options to unbootstrap a project.
Quoting Ralf Wildenhues [EMAIL PROTECTED]:
Hello Benoit,
* Benoit Sigoure wrote on Sun, Jun 17, 2007 at 01:16:35AM CEST:
I've reviewed the patches I proposed back in March, completed them with
tests, ChangeLog and NEWS entries. If they are accepted, I'll write the
documentation.
Please write the documentation. ;-)
PPS: Although this would belong to
{autoconf,automake,[EMAIL PROTECTED], I only sent it to the
Autoconf ML because Autoconf has the biggest patch and I expect Automake
and Libtool maintainers to see this message. I hope my assumption
wasn't wrong :)
Well. One purpose of the different lists is that, a couple of years
down the road, one can still dig out useful information from the
archives. And I personally tend to look for patches to some package
only in my $PACKACKE-patches list archive. So please send each patch to
its list. Thank you.
2007-06-17 Benoit Sigoure [EMAIL PROTECTED]
* automake.in, aclocal.in: New option `--clean'.
($clean, @files_installed): New.
* automake.in (require_conf_file): Save the list of files to be
removed in @files_installed.
* aclocal.in (install_file, write_aclocal): Likewise.
* NEWS: Mention the new option.
* tests/Makefile.am, tests/Makefile.in: Add the new test.
* tests/unbootstrap.test: New.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
This message was sent using IMP, the Internet Messaging Program.
Index: NEWS
===
RCS file: /sources/automake/automake/NEWS,v
retrieving revision 1.326
diff -u -r1.326 NEWS
--- NEWS29 Mar 2007 23:01:59 - 1.326
+++ NEWS18 Jun 2007 22:20:06 -
@@ -15,6 +15,9 @@
- install-sh supports -C, which does not update the installed file
(and its time stamps) if the contents did not change.
+ - automake and aclocal support a new `--clean' option that undoes the job
+done by `--add-missing'.
+
Bugs fixed in 1.10a:
* Long standing bugs:
Index: aclocal.in
===
RCS file: /sources/automake/automake/aclocal.in,v
retrieving revision 1.140
diff -u -r1.140 aclocal.in
--- aclocal.in 14 Oct 2006 17:40:25 - 1.140
+++ aclocal.in 18 Jun 2007 22:20:06 -
@@ -8,7 +8,7 @@
# aclocal - create aclocal.m4 by scanning configure.ac
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
-# 2005, 2006 Free Software Foundation, Inc.
+# 2005, 2006, 2007 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -77,6 +77,12 @@
# Option --force.
my $force_output = 0;
+# Option --clean.
+my $clean = 0;
+
+# Files to remove with --clean.
+my @files_installed;
+
# Modification time of the youngest dependency.
my $greatest_mtime = 0;
@@ -248,6 +254,11 @@
if $res;
unlink_tmp;
}
+ elsif ($clean)
+ {
+ # Remember that we must remove this file once we're finished.
+ push (@files_installed, $dest);
+ }
elsif (!$dry_run)
{
xsystem ('cp', $src, $dest);
@@ -773,6 +784,14 @@
return 0;
}
+ # We are now about to output `$output_file'. If we're in clean mode, we
+ # shall just stop here.
+ if ($clean)
+{
+ push (@files_installed, $output_file);
+ return 1;
+}
+
# Nothing to output?!
# FIXME: Shouldn't we diagnose this?
return 1 if ! length ($output);
@@ -857,6 +876,7 @@
Options:
--acdir=DIR directory holding config files (for debugging)
+ --clean remove files installed by aclocal
--diff[=COMMAND] run COMMAND [diff -u] on M4 files that would be
changed (implies --install and --dry-run)
--dry-run pretend to, but do not actually update any file
@@ -915,6 +935,7 @@
'diff:s' = \$diff_command,
'dry-run' = \$dry_run,
'force' = \$force_output,
+ 'clean' = \$clean,
'I=s' = [EMAIL PROTECTED],
'install' = \$install,
'output=s'= \$output_file,
@@ -986,6 +1007,11 @@
$dry_run = 1;
}
+ if ($clean $install)
+{
+ fatal 'Cannot install and clean at the same time';
+}
+
if ($install [EMAIL PROTECTED])
{
fatal (--install should copy macros in the directory indicated by the
@@ -1050,7 +1076,29 @@
last if write_aclocal ($output_file, keys %macro_traced);
last if $dry_run;
}
-check_acinclude;
+check_acinclude unless $clean;
+
+if ($clean)
+ {
+if ($dry_run)
+ {
+foreach my $cleanfile (@files_installed)
+ {
+ print rm -f $cleanfile\n
+ unless not -e
Re: Determine Data Root Directoy in code
Ralf Wildenhues wrote: Does this help? http://www.gnu.org/software/autoconf/manual/html_node/Defining-Directories.html Cheers, Ralf Yeah! That helped alot. Thanks, Jeshua -- View this message in context: http://www.nabble.com/Determine-Data-Root-Directoy-in-code-tf3917223.html#a11181617 Sent from the Gnu - Automake - General mailing list archive at Nabble.com.
Automake violations of the gnu coding conventions
I notice that automake is currently generating Makefiles that violate the gnu coding conventions. Specifically, it's generating rules for rebuilding Makefile from Makefile.in and Makefile.in from Makefile.am which requires automake. And yet the gnu coding standards specify: The |configure| script and the Makefile rules for building and installation should not use any utilities directly except these: cat cmp cp diff echo egrep expr false grep install-info ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch true Note that automake is not in this list. Also, in the past, there were coding standards that prohibited Makefiles from writing into $(srcdir). The problem here is that source code directories might be read-only as comes from a cdrom, or from a shared but not owned source directory, (perhaps on a network server). Note that these problems are particularly troublesome when one uses a file transfer method for copying or moving source trees that doesn't necessarily retain last modification time stamps, like source code control systems, cp, etc. In these cases, the source directory becomes unbuildable. My question today is... is there any hope of bringing automake generated Makefiles back into line with the GNU coding standards so that these applications will work once again? I mean, I'll be happy to do the work and to submit diffs, but would such a change be accepted back into the automake code stream? --rich
Re: Automake violations of the gnu coding conventions
On Mon, 2007-06-18 at 17:27 -0700, K. Richard Pixley wrote: My question today is... is there any hope of bringing automake generated Makefiles back into line with the GNU coding standards so that these applications will work once again? Use AM_MAINTAINER_MODE in your package; this will disable the rules to rebuild Makefile.in etc unless --enable-maintainer-mode is supplied by the user. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Automake violations of the gnu coding conventions
Bob Proulx wrote: K. Richard Pixley wrote: I notice that automake is currently generating Makefiles that violate the gnu coding conventions. Hmm... I don't think that automake violates the standards. In the normal case it is not required to have automake installed. Someone who is simply building from the generated Makefiles never needs to have automake installed. Only a developer who is modifying the automake source files would need automake installed. But that's my point. With the defaults as they are now there are many normal cases where automake is required. Since it should not be, I submit that automake is broken in that it violates the gnu standard. Obviously from the questions you are asking you are experiencing a specific problem. Could you share some details? I have already done so. The actual use case is somewhat more involved than is necessary to explain the problem. However, do the following. Untar your favorite AM configured program. Remove automake from your system. Do find . -name Makefile.am | xargs touch, then configure, make all check install as usual. You'll see the problem immediately. Specifically, it's generating rules for rebuilding Makefile from Makefile.in and Makefile.in from Makefile.am which requires automake. Rebuilding the generated Makefile.in file is only needed if the source file is modified. You are correct in that it is only needed in this case. However, there are many other cases where it is being regenerated because there are many other cases where the file time stamps are adjusted, lost, or randomized. I don't see a good alternative in that case. The GNU coding convention would seem to suggest that the right answer is to decline to rebuild Makefile.in automatically. it's ok if there's a make automake or some such, but you can't simply let Makefile depend on Makefile.in depend on Makefile.am because doing so requires the user to have automake installed in order to build in some cases. If the automake source file is modified then presumably the person doing the modification wants the change and then automake would be required. Not necessarily. There are a number of cases, (cvs), where Makefile.am has a more recent modification date that Makefile.in. It hasn't actually been modified, but you can't tell that solely from file time stamps. Anyone doing this would fall into the developer role and there is an expectation that developers must have the appropriate tools available. If you are not modifying the automake source files then automake is not required. Only if they were actually changing the file. If they were, say, cp -r'ing a tree from their neighbor, they aren't necessarily developing, and yet they are suddenly forced to have automake installed. Also, in the past, there were coding standards that prohibited Makefiles from writing into $(srcdir). The problem here is that source code directories might be read-only as comes from a cdrom, or from a shared but not owned source directory, (perhaps on a network server). Please use VPATH builds for read-only source directories. This doesn't solve the problem Im talking about. The rule I'm complaining about is, in part: $(srcdir)/Makefile.in: Makefile.am blah, blah, blah This rule attempts to write to the, (potentially read-only), source directory and is, I claim, therefor broken. Example: mkdir /tmp/project cd /tmp/project /media/cdrom/project/configure That is an example build from a read-only source directory. Which will fail when make tries to run automake to regenerate Makefile.in, since that directory is read-only. Note that these problems are particularly troublesome when one uses a file transfer method for copying or moving source trees that doesn't necessarily retain last modification time stamps, like source code control systems, cp, etc. In these cases, the source directory becomes unbuildable. When filestamps are munged then the simple action of touching all files to the same timestamp is a good workaround. find . -type f -print0 | xargs -r0 touch -r configure.ac This will also break given the current set of rules. You won't be able to build without automake, and even if automake is present, you'll still be hosed if the source directory is read-only. Normally I would avoid munging timestamps of files. However in the case that they are already munged then I see no additional problem with getting them all into a consistent state. Munged here is a very subjective perspective. Cp -r will create a source tree that can't be built using the current rules. So will checking the tree into, say, cvs or perforce and then checking it out. Again, I would appreciate it if you would describe the problem that you are experiencing that has led you here with a complaint about automake. I've already done so, but here's a repeat of most of those problems. BTW, this argument isn't new. I had the
Re: Automake violations of the gnu coding conventions
K. Richard Pixley wrote: even be interested in regenerationg Makefile.in's automagically. As is, typical builders, (ie, not maintainers), are required to install automake in order to build packages requiring automake. I think you're generalizing this to a degree that's not the case. Most users that build from source do so from a tarball, and since tar preserves timestamps they should be correct and the user won't need developer tools regardless. Many, if not all, of the GNU packages that do store generated files in version already use this option and thus don't require any developer tools. Examples: gcc, binutils, gdb/insight, and the entire sourceware tree. The remaining GNU packages that don't store generated files in version control by definition require developer tools to build from CVS, so the option is irrelevent here as well, since again a tarball has the required timestamps. Examples: libtool, m4, coreutils. When you eliminate all of the above you're down to a very limited portion of use cases, and if installing developer tools is not an option then the problem can be solved by simply using a tarball, using cp -p, find | xargs touch, etc. really solve the problem for users. Now if generated makefiles could have those rules turned off using a command line and/or environment variable, that might be useful. Then we could build packages without automake, so long as we had AM_MAINTAINER_MODE=no in our environment. But again, I'd argue that it was the maintainers who should set the variable and that the default should be no dependency on automake. --disable-maintainer-mode ought to work, but I haven't tried it. Brian
Re: Automake violations of the gnu coding conventions
On Mon, 18 Jun 2007, K. Richard Pixley wrote: Bob Proulx wrote: Are we talking about one of your own projects? Or are we talking about other projects that you are trying to build? Projects that I'm trying to build. Hundreds of them. Projects that won't be fixed in their current incarnations even if we correct automake now. It'll Since you can't fix all these projects at once, then I suggest to stop using the MS-DOS FAT filesystem due to its poor timestamp resolution. Use NTFS instead. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
