[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Gary V . Vaughan
Thu, 9 Aug 2001 00:33:31 +0100
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
> > 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
> > > 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
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
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
())_. 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__/
|[Prev in Thread]
||[Next in Thread]|
- Re: M4,
Gary V . Vaughan <=
- Next by Date:
- Next by thread: