Hi!
>--[Bernard Dautrevaux]--<[EMAIL PROTECTED]>
> >--[Alexandre Oliva]--<[EMAIL PROTECTED]>
> > >--[Jim Meyering]--<[EMAIL PROTECTED]>
> > > 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.
> 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).
Hey, he's talking about *me*! ;)
Right now, I'm struggling with ncurses - the author had the absolute
ingenious idea to patch autoconf, causing me lots of grief.
> In this case the problem is not AMA or m4/*.m4; it's usually fixing
> some macros that wrongly run some tests.
Or do not cache values so that I could put them there before.
If I'd know where those macros came from, I could change them there. Now,
the only way is to patch aclocal.m4, which is bad.
It would be much nicer if it would be like config.(sub|guess): Send a
patch to the author, then replace every config.(sub|guess) encountered
with the new version. In other words: patch somefile.m4, and then
replace all somefile.m4's found in different packages with the new
version.
> 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? :-))
Well, autoconf doesn't :(.
> 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.
The point was that this requires work to implement. Somehow I'd
appreciate a stable autoconf >2.13 as soon as possible since then I can
point some mor^h^h^hpackage maintainers to it.
Just my 0.02 Euro.
Yours, Rüdiger.
