[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compatibility of modules across releases
From: |
Gary V . Vaughan |
Subject: |
Re: Compatibility of modules across releases |
Date: |
Thu, 9 Aug 2001 19:58:14 +0100 |
On Thursday 09 August 2001 11:13 am, Akim Demaille wrote:
> I have a simple question: what is the scheme that is chosen for binary
> incompatibility between releases of m4?
In the usual way, by tracking interface numbers with the libtool version
number of libm4. When a binary incompatible change is made that is exposed
across the interface to libm4 used by m4 itself or m4 modules, set the C:R:A
appropriately compared to the previous revision.
This probably means that modules themselves will also need to maintain a
libtool version number...
> I have a concrete examples: I'm toying with something named dumpstat
> which currently merely counts the number of invocations of a macro,
> which means I have changed the struct macro and struct builtin. So I
> guess it means my modules are incompatible with natural modules.
Just follow the interface version numbering rules in the libtool manual (and
Goat Book).
> Maybe some day this will become a --profile supported by m4 itself.
> So it might be an incompatibility between 1.5 and 1.6. How will we
> handle this? Probably by changing the name of libexec, but I just
> wanted to know what's the clean means to do that.
I'm not sure how to handle that. How will a module built outside the m4 tree
know where to install itself if there are several m4 binaries available? It
would be nice if m4 itself could reject a module built against a different
version of libm4 to the one already linked into the binary... once the system
loader has started complaining (if it is sophisticated enough), it may be too
late to make a clean recovery.
We could use the libtool --release flag with the M4 version number for all
modules, and the C:R:A libtool version to maintain interface compatibility
information in revisions of the module. Building a module outside the M4
tree would use the following:
libtool --mode=link gcc -o foo.la --release `m4 --version` \
--version 0:0:0 foo.lo
> I have another concrete example: I also have changed __line__ and
> __file__ so that __file/line__(MACRO) expands to the file/line where
> the MACRO was defined. Again, this means some low level structs have
> changed, hence, I guess, binary incompatibilities.
Same deal here too.
Cheers,
Gary.
--
())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org)
( '/ Research Scientist http://www.oranda.demon.co.uk ,_())____
/ )= GNU Hacker http://www.gnu.org/software/libtool \' `&
`(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/