autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Site Macro Directory


From: Mark D. Roth
Subject: Re: Site Macro Directory
Date: Sat, 18 May 2002 17:50:40 -0500
User-agent: Mutt/1.2.5i

On Sat May 18 14:56 2002 -0700, Paul Eggert wrote:
> Yes, but the cure of having two subdirectories is worse than the
> disease.  It will complicate the explanations to users, and will
> complicate source directory structures, and will lead to lots of
> confusion.
> 
> I think it would be better to stick to m4 as the subdirectory, and to
> come up with a transition strategy.  Basically, the problem here is
> that an auxiliary tool (aclocal) is being used to do a function that
> you think should be done by autoconf itself, and you need to come up
> with an upgrade path that won't break anything while people are
> upgrading to new Autoconf and Automake releases.
> 
> Here is one way to do this; perhaps you can think of improvements.
> The end result of this upgrade path will be a situation where aclocal
> no longer copies m4/*.m4 into aclocal.m4.  The first step of the
> upgrade path is to modify Autoconf to support AC_INCLUDE.  The second
> step is to modify aclocal to put AC_INCLUDE(foo.m4) into aclocal.m4
> instead of bodily copying m4/foo.m4.  People like you who don't want
> to use aclocal can put AC_INCLUDE(foo.m4) into their configure.ac file
> or aclocal.m4 by hand, and use the new version of Autoconf.  People
> who use Automake and do not modify their source files will not be
> affected by either step (1) or step (2), except that their aclocal.m4
> files will get smaller and easier-to-read after step (2).

I think we're miscommunicating somehow.  Let me try to clarify what
I'm proposing by explaining it in terms of what modifications need to
be made to autoconf.

First, autoconf will be modified to read all of the m4 files in the
`ac-package' subdirectory.  Just as with the aclocal.m4 file, these
files will be read automatically; no AC_INCLUDE macro will be
necessary to read individual files.  This should not present a
scalability problem because only the set of macros required for the
package will be placed in the package's `ac-package' subdirectory.

Second, an AC_SITE_INCLUDE macro will be added to allow individual m4
files to be read from the system's site macro directory.  This macro
will only be used to read files from the site macro directory; it has
nothing to do with the files in the package's `ac-package'
subdirectory described above.  The reason for using a macro to select
individual files instead of simply reading every file in the site
macro directory is that, unlike an individual package's `ac-package'
subdirectory, the site macro directory will contain a large number of
macros, and not all of them will be needed for the package.

If it helps, think of these two modifications as two different
proposals, since they're really meant to address two different needs.
The `ac-package' subdirectory will address the need for a more
convenient way to ship multiple macros files with the package.  The
site macro directory will address the need for a way to distribute
macros independent of a particular package.

Given these modifications, the transition plan that I'm proposing is
the following:

  1. Add `ac-package' modification to autoconf.  Users can upgrade to
     the new version of autoconf without affecting their current
     aclocal functionality, since aclocal uses a different
     subdirectory.

  2. Users can migrate from using aclocal to using new autoconf
     functionality by renaming their `m4' subdirectory to
     `ac-package', after which they no longer need to run aclocal.

  3. Once the user community has migrated away from aclocal, it can be
     removed from the automake distribution.


> Sorry, I'm a bit lost.  What are the differences between m4_include,
> AC_SITE_INCLUDE, and the old AC_INCLUDE?  Is it merely that
> AC_SITE_INCLUDE looks only in the site directory, and not in the m4/*
> subdirectory?

>From what I see in CVS, the old AC_INCLUDE macro was exactly the same
as m4_include (although I could be reading it wrong).  The
AC_SITE_INCLUDE macro that I'm proposing would look only in the site
macro directory.


> This sounds too aggressive to me.  It's a bit like saying that you'll
> have a C include directory, and the C compiler will automatically
> include every .h file under that directory.

For the site macro directory, I agree with you, which is why
AC_SITE_INCLUDE is needed.  For the package's `ac-package'
subdirectory, this shouldn't be a problem, because it will only be
used to contain the particular set of macros needed by the package.


> Under the counterproposal mentioned above, autoconf would read the m4
> file only if explicitly requested with an AC_INCLUDE.  An advantage of
> this method is that sometimes (unfortunately) there are dependencies
> among .m4 files (one must be included before another), and the user
> can handle this by including the .m4 files in the proper order.

I don't think I've ever run into this with any of the macros that I've
written.  Can you give me a concrete example of this?  I would think
that this problem could be avoided by proper quoting and using
AC_REQUIRE or AC_BEFORE.


Anyway, I hope this clarifies what I'm proposing.  I'm sorry for the
confusion.

As always, all comments and feedback would be appreciated.

-- 
Mark D. Roth <address@hidden>
http://www.feep.net/~roth/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]