> -----Original Message-----
> From: Alexandre Oliva [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 03, 2000 10:38 PM
> To: Jim Meyering
> Cc: Akim Demaille; Autoconf List
> Subject: Re: Autoconf Extension Files
>
>
> On Aug 3, 2000, Jim Meyering <[EMAIL PROTECTED]> wrote:
>
> > we'll never be able to go back to a simpler and cleaner approach.
>
> The problem is that I don't agree that keeping multiple m4 files in
> the source tree is a simpler and cleaner approach. I think
> maintaining a single aclocal.m4 is simpler and cleaner.
>
> That's the whole point of the debate.
>
Let me apologize to jump in a so long debate already but I think there is a
point that was not discussed before: we look at Joe D. Velopper (a newbie
package creator) and at Mike X. Pert (an expert package maintainer), but
never think at Rand Porter, the standard guy that get porting packages on
some exotic configuration that was not expected by the original package
maintainer (like for example cross-compiling).
In this case the problem is not AMA or m4/*.m4; it's usually fixing some
macros that wrongly run some tests. Waht in this case IS needed is an
acllocal-like tool that understand the way the package was built (AMA/split
files) but is able to update simply a give set of AC_XXX macros (let call
this a module).
Oh I hear you: I can patch aclocal.m4 !-)
Right but I have to do that for all the packages I want to port, and that
may be a lot of duplicate work, and I may discover an error in my patch and
I have to patch againg the tens of aclocal.m4 files that lay in all these
packages (I'm not going to talk of zillions hopefully :-)
The problem with the current aclocal.m4, is that if I "aclocal" and the
package maintainer use some exotic macros I don't know about, autoconf will
just generate a configure script that will fail when trying to execute the
command "AC_EXOTIC_MACRO(some args)" (or do I forget that aclocal will
nicely says that AC_EXOTIC_MACRO was not found and refrain from erasing my
aclocal.m4 file? :-))
Sure in this case Akim's solution is nice, as I can replace the module I
need by my corrected/enhanced version, and send a simple patch to the
maintainer if that is not too specific. But a (simple ?-() evolution of
aclocal may also fit the job:
1) Prefix all module.m4 file inlining by some comment saying: "this is
coming from module.m4"
2) Build the list of macros defined by aclocal.m4, attributing them to their
original module (if prefix comment were in aclocal.m4) or to an
"auto-inlined.m4" pseudo module
3) Build the list of macros needed by the configure.in file (I think this is
already done by aclocal)
4) Build the list of .m4 files from the local .m4 file library (or from a
distributed m4 subdirectory) needed (already done at least partially)
5) Suppress from the list of aclocal-inlined modules all modules that do not
define any macro that is not defined by the files found by 4)
6) Check no macro is defined by two modules coming either from the original
aclocal.m4 file or from locally installed .m4 files; for any conflict print
a warning and if there is any warning stop there
7) Create the new aclocal by merging all needed modules coming from either
the original aclocal.m4 or from installed .m4 files.
This should also be able to simply display the list build in step 2) or to
extract one of these modules, for sending patches to the maintainer.
The additional advantage here is that this would help moving to a more
modular way of working, even if you're not the maintainer of the package. If
you get a copy of the more often used m4 modules (just first get the whole
macro archive...) the new aclocal may just be able to keep the existing
macros but add the names of the installed modules in which it find the
corresponding macros :-)
Don't forget: we are not all package maintainers, there's also a lot of
simple builders that may have to twaek packages a bit if they do not build
out-of-the-box, especially if they are no more actively maintained, so an
evolution of aclocal should, if possible, help migrating to the new scheme.
I'm not really favoring either Akim's or Alexander's proposal: this can be
implemented as a fully-split aclocal.m4 by just "exploding" aclocal.m4,
defining module names either by prefix comments or by matching the macros
contained with those in the local autoconf m4 library.
This approach is probably a bit more simpler to implement, but perhaps not
so much; the main advantage is that this split mechanism could be a simple
conversion tool, then you may refine the result, decide module by module if
you want to use the local one or the installed one (just delete the local
one) , then rebuild aclocal.m4 either by inlining or including. Inlining has
slightly my preference as this allows just to distribute the compound
aclocal.m4 file, while still having the ability to "explode" it and manage
it locally by cp/ln/rm.
Just my 2 cents
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]
--------------------------------------------
