Re: M4

[Gary V . Vaughan]

Hi Akim,

Moved to m4-discuss...

On Wednesday 08 August 2001 7:40 pm, address@hidden wrote:
> On Tue, Aug 07, 2001 at 10:21:30PM +0100, Gary V. Vaughan wrote:
> > On Tuesday 07 August 2001 9:17 am, Akim Demaille wrote:
> > > Currently, I see no simple idea to have it work for both the being
> > > built m4, and the installed headers.
> >
> > Ah yes.  I did fix this by installing m4_obstack.h if the system file was
> > missing, but it met with some resistance so I reverted it.  I don't
> > recall the particular issues that were debated... is there an archive of
> > m4-forum?
>
> I think so, but I don't have my web handy :)

I had another quick look, but couldn't find anything from Rene's site.  No 
matter.

> > If not I have a near complete archive of my old mail on CD that I could
> > hunt through to refresh my memory, and save retreading the same ground
> > again...
>
> I don't think it is that important, we will sure find a means to do that
> cleanly.

True.

> > > Well, my problem is about aesthetics: some files have mixed style.
> >
> > Eeew.  I expect that is fixed with my unchecked-in working copy.  Even
> > so, the files that are maintained outside of m4 (obstack.c for example)
> > might be ANSI...
>
> Yes, I still believe today we should program in C 90, and actually even
> C99. ansi2knr is here for KnR, we should not promote deprecated languages
> :P

Fair enough.  Actually I would be interested to find what are the precise 
differences between the two.  Is this documented anywhere (without paying for 
specification docs from the standards committee that is)?

> > > I would like to clean up the package a little bit:
> > > add config/Makefile.am  to make it a regular package
> >
> > Why do you think this is a clean-up?  Since nothing is built from the
> > config directory, I actually prefer to distribute the config files from
> > the top-level directory, and save on file clutter.  There is also one
> > less useless Make recursion for every build/check/dist etc...
>
> Agreed with all these points, but I think we should teach the most
> straightforward way to do things.  In fact, I have since applied these
> changes, sorry if you did not want them :(  The main reason was that I
> grew tired of struggling with distcheck.  In particular your approach,
> which is not based on Automake shipping the files, can have as a side
> effect of forgetting newly required Automake files that Automake knows
> it has to ship, but your static rules don't

That is true, but then that is what distcheck is there for.  I'm not keen on 
this change, but since it is in, I don't feel strongly enough about it to 
revert.  We can debate this some more when we are closing in on an actual 
release if necessary.

> > > require 2.52
> >
> > Agreed.
>
> I have a few further patches to apply for this issue, mainly dealing
> with the fact that autom4te catches your m4_ variables and thinks they
> are unexpanded M4sugar macros :)

I had meant to fuss about this on address@hidden but seem to have been 
distracted.  Surely M4 has a strong claim on the m4_ namespace?  Oh well, 
never mind.  I should have complained earlier ;-)  If there is an elegant way 
to allow M4 to have access to that namespace without too much upset, I'd 
still be keen to do that.  But I don't think it is important enough to fret 
over...

Wow.  I hadn't realised what a miserable old bugger I have become until I 
proof read my comments in this email.  Bah!  Humbug!  :-v

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