>>>>> "Bernard" == Bernard Dautrevaux <[EMAIL PROTECTED]> writes:
Salut Bernard !
Bernard> The problem with the current aclocal.m4, is that if I
Bernard> "aclocal" and the package maintainer use some exotic macros I
Bernard> don't know about, autoconf will just generate a configure
Bernard> script that will fail when trying to execute the command
Bernard> "AC_EXOTIC_MACRO(some args)" (or do I forget that aclocal
Bernard> will nicely says that AC_EXOTIC_MACRO was not found and
Bernard> refrain from erasing my aclocal.m4 file? :-))
I think we all agree that Automake's aclocal is doing a poor job, in
particular because it just concatenates. There is a critical need for
something which makes it possible to update logical chunks, aka
modules. Both Alexandre and I do intend to address the issue.
(Alexandre's proposal does include a --split/--join.)
The steps you gave is what we want to do. I might add that personally
my goal is to have `autoreconf' do all this as automatically as we
can. I do think about Rand, and also to Hans Taller, because they
might want to
tar zxvf foo-0.1.tgz
cd foo-0.1
autoreconf
and proceed knowing that DESTDIR is supported, config.guess is updated
(why not, now that we have a means to compare versions) etc.
Bernard> I'm not really favoring either Akim's or Alexander's
Bernard> proposal: this can be implemented as a fully-split aclocal.m4
Bernard> by just "exploding" aclocal.m4, defining module names either
Bernard> by prefix comments or by matching the macros contained with
Bernard> those in the local autoconf m4 library.
Right. This is definitely what Alexandre suggests.
There is something which I should probably clarify on the state of the
debate today.
Alexandre and I agree we need a tool.
We both agree we need to ease updates.
We agree includes give you more chances to shoot yourself in the foot
(but I think Alexandre ranks higher this likelihood than I do, and
that he sees failures are problematic while I think nothing big
happens if you forget to cvs add or to ship a missing m4 file).
We agree 100% include and 100% inline are both good answers.
We disagree on the room left in between. I think it should remain a
non Mike-Joe-Hans-Otto-Rand land, he thinks we should offer the means
to have both includes and inlines. I think it's way too many
complications, too much documentation to read, too many additional
means to shoot in the very hand holding the gun :) He thinks that's
worth it and that anyway it's gonna be simpler than I fear.
Well, that's what I understood :)
