Re: Compatibility of modules across releases

[Gary V . Vaughan]

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__/