bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnulib] uniform #serial number for M4 macros, and `aclocal --in


From: Alexandre Duret-Lutz
Subject: Re: [bug-gnulib] uniform #serial number for M4 macros, and `aclocal --install'
Date: Wed, 02 Feb 2005 23:14:55 +0100
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

>>> "James" == James Youngman <address@hidden> writes:

[...]

 James> A serial number for each macro or for each M4 file?  I think the
 James> difference is important.  From other things in this excerpt it is
 James> clear to me that "each M4 file" is meant.  It might be a good idea to
 James> be very clear about the distinction in the documentation.

Yep.  I'll do, thanks!  

 >> It allows version-like strings such as `1.2.3' because I saw CVS
 >> libtool was using one, and I find it to be the only practical
 >> way to handle branches and forks.

 James> I suspect that this is not a practical way to handle
 James> branches either.

It does not help in the case you describe, indeed.  But on that
point I was thinking about the macro author, not the macro user.

When you maintain an M4 macro in a project with branches (e.g.,
libtool, automake), it's possible for the macro on each branch
to have different evolutions.  Using a single number make it
very hard to handle this.  Allowing version strings let you
apply a numbering scheme similar to that of CVS (for instance).

 James> If I have one file "setup.m4" which contains only the macro
 James> "foo_SETUP" and another file elsewhere also called "sertup.m4" which
 James> contains only the macro "bar_SETUP", would this have worked
 James> historically.  

Historically, yes.

 James> Would it have worked historically if only the 'bar' one
 James> contains a serial number?

Historically serial number were ignored, so yes.

 James> Now, if the 'foo' file has a #serial line inserted into
 James> it, will this stop the 'bar' package from working?

Historically this would have worked too.

Now with the current CVS code, all the above cases will continue
to work as they did as long as you do not use the `--install'
option.  (The only slight difference is that aclocal will warn
if it can't parse some serial number; but it will NOT use these
serials and continue to work as it did.)

Now if you use --install and at least one of the two files has a
#serial, then things will (expectedly) break, because of the
semantic of #serial.  (A file without serial is assumed to be
older than a file with a serial.)

If you use --install and none of the files use #serial, the
outcome will depend of where the files are located.  Or more
precisely, whether they need to be installed.  Obviously the two
files cannot be both installed by aclocal (it would do it in the
same place), so this setup will work only if one of the two
files is already installed in some subdirectory of your package
that is not the destination of --install.  In that case aclocal
can install the other file, and m4_include both.

[...]

 James> 
^[[:space:]]*#[[:space:]]*serial[[:space:]]+[0-9]+[0-9\.]*\([[:space:]].*\)?$

Are the spaces before # needed for some reason?  I'd prefer to
disallow them.  I don't think any tool ever used this.

[...]

 James> Will this behaviour be switchable on a per-system basis?
 James> I'm thinking about people who work with old code but
 James> keep up to date with system software patches.

This new behavior is enabled only when you use --install.
-- 
Alexandre Duret-Lutz





reply via email to

[Prev in Thread] Current Thread [Next in Thread]