bug-m4
[Top][All Lists]
Advanced

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

Re: M4


From: akim
Subject: Re: M4
Date: Wed, 8 Aug 2001 20:40:51 +0200
User-agent: Mutt/1.3.18i

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 :)

> 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.

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

> > 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.

> > 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 :)



reply via email to

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