> -----Original Message-----
> From: Earnie Boyd [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 04, 2000 6:40 PM
> To: Akim Demaille; Bernard Dautrevaux
> Cc: 'Alexandre Oliva'; Jim Meyering; Autoconf List
> Subject: Re: Autoconf Extension Files
>
>
> --- Akim Demaille <[EMAIL PROTECTED]> wrote:
> >
> > 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.
> >
>
> Thanks for the clarification on this matter. So, the debate
> isn't to include
> or not to include and it isn't to inline or not to inline but
> it is whether to
> have both options.
>
> My choice is for both options.
>
I'm not sure I understand exactly what Akim's wanted to say, but what I
understood is that Akim and Alexandre agree that it was needed to be able to
BOTH:
have an all-contained aclocal.m4
have an aclocal.m4 which just m4_include files that are provided in
a sub-directory
What I've understood is that Alexandre also advocates the possibility to
have an aclocal.m4 which both contains AC_DEFUNs and m4_include files. I'm
not sure that is terribly different from just having one more file in the
sub-directory.
If the revamped aclocal is able to join/split aclocal.m4 (like for example
how I sketched in a previous message) I think we do not need more; the only
difference is what to do with macros that are not attributed to a given
module: Akim (and I for the sake of orthogonality) say "attribute them to
some default sub-file" and Alexandre says "leave them where they are, that
is in aclocal.m4".
As a matter of fact I do not see much difference, neither in implementation
(as we need to be able to take care of existing non-splitted/non-tagged
aclocal.m4 files) nor in convenience. So I would say: let the one that wants
to create the tool go the way he wants... :-)
The problem in estimating the cost of implementation is that for a pure
split/join scheme without the complexity of the mixed aclocal.m4, we may
forget the cost of the first splitting of the original aclocal.m4. This
automated split IS needed as a lot of existing packages out here have to be
ported (even if they are no more maintained) so this upgrade has to be done
by the porter.
Once this is implemented the cost to maintain Alexandre's mixed scheme is
essentially null. The only thing is an extra option to decide what to do of
macros that are not assigned to an explicit macro-module file.
Regards,
Bernard
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
--------------------------------------------
