Re: M4 in SuSE 7.2

[Gary V. Vaughan]

On Sun, Oct 14, 2001 at 10:09:45PM +0200, Santiago Vila wrote:
> On Sun, 14 Oct 2001, Gary V. Vaughan wrote:
> 
> > On Sat, Oct 13, 2001 at 08:41:19PM +0200, Santiago Vila wrote:
> > > Interesting. Am I allowed to put m4-1.4o in Debian?
> >
> > Absolutely.  I have been using it for well over a year as my production
> > M4.  I wouldn't put it in stable just yet mind you...
> 
> That's the problem. If I upload it for Debian unstable, it will become
> part of `testing' (codenamed `woody') in ten days, and will eventually
> be part of stable when woody becomes the new stable (which might happen
> this year).

That's true... but then being in Debian, and successfully making the
transition to stable via the route you describe must show that the code is
stable enough to warrant it, no?  I just meant that I wouldn't recommend
dropping it right into stable straight away.

> So: What's left for m4 to be released as 1.5? For example:
> 
> * Is the documentation in sync with the code changes since 1.4?

Yep.  As far as I know... I have been quite careful to include relevant
documentation changes with the code patches.  It could probably use a proff
reading pass though.

> * Does it have some obscure bug which has not been fixed yet?

Nope.  Except for a small known way to crash the format function, which we
plan to fix by incorporating my snprintfv library (as used by AutoGen) --
which *does* have a known showstopper bug :-(  And I don't have the time to
work on snprintfv at the moment.

> * Is there a wait for a new automake/autoconf/libtool release or something?

Nope.  Although it does require a bleeding edge autoconf in order to bootstrap
the new test suite.

> Last time I asked about a release date I was told m4-1.5 would be
> released "next spring" (but it was spring of the year 2000 :-).

It has been on the verge of a new release for about 2 years now I think... I
seem to fallen in to the role of chief maintainer of M4 for the time being,
and since I am writing a book that talks about 1.5 in the past tense, I
*really* want to have it out of the door before the book hits the shelves
early next year.

> If the current code is much better than m4-1.4 and m4-1.4 is seven
> years old, why not release the current code as m4-1.5, instead of
> trying to make it "perfect"?

The main problem is that the new module syatem is very dirty.  Well not the
module system per se, but the API.  I basically broke m4 into 3
sections... most of it is in a library (libm4) and exports just about
everything, the builtins are now in modules, and M4 the executable is a thin
wrapper for argv parsing and segv handling.

I would not be happy about dubbing any release with such an ad hoc API as
stable... knowing full well that I will need to shake it up massively before
the next release, and break all the modules people have written against the
current API.

However, there is something to be said for making a branch at 1.4o,
backporting any bugfixes and making a 1.5 release from there... I am open to
persuasion from other members of the list :-)

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