Re: Site Macro Directory

[Mark D. Roth]

Sorry for the delay in responding.  This has been an unusually busy
week...


On Tue Jul 30 18:58 2002 +0200, Alexandre Duret-Lutz wrote:
> I second Akim here.  A package ought to come with its entire
> source code, including the source for things like `configure'.
> That's configure.ac plus any non-standard macros.

How is this different from a package that uses an external library?
If I'm maintaining a package that uses a library that someone else
wrote, I'm not going to include a copy of the library's source code in
the source distribution of my package.  It's much more efficient to
simply point the user at the home site of the library and tell them
that they need to install it before they can build my package.


> Supporting a Site Macro directory in Autoconf seems a good step
> towards the elimination of `aclocal' (from Automake), but
> probably it should not be the role of `autoconf' to scan this
> directory.
> 
> I like the idea Akim presented earlier in this thread: having a
> separate tool (an aclocal replacement) that imports all needed
> macros in the current project.  

If it's absolutely necessary to include these macros in the package
that uses them, I submit two things for consideration.

First, this functionality SHOULD be provided by autoconf rather than
by yet another external tool.  (It can be done in a "preprocessing"
phase before autom4te is invoked, but it should happen automatically
when the developer runs "autoconf".)  We already have too many
different tools that interact with each other in too many different
ways, and adding another one would be a step backwards.  What we need
to do here is to consolidate the core functionality into a single tool
so that it's available without the developer needing to take any extra
steps.

Second, I think that the behavior of whether or not to add the macros
to the package should be configurable by the developer.  If the GCS
mandates that all macros are included, then this behavior can be used
by GNU projects, but other developers may want to use the other
behavior.


> I don't think this goes against your will of packaging a set of
> macros.  You still install macros in the Site Macro directory,
> but from there they are copied automatically into each "client"
> package.

As I said above, this is fine as long as the copying happens
transparently when autoconf is run.


> It's a problem for the same reason /usr/share/aclocal/ is a
> problem.  If a package relies on this directory (i.e., if it
> doesn't ship with all the macros it uses), then it's impossible
> for a user to regenerate ./configure without installing all the
> packages required to populate /usr/share/aclocal/ with the right
> macros.

That's true, but I'm not convinced that this is a serious problem in
most cases.  It's usually not a big deal for a user to download and
install prerequisites before installing a package.


> Let's take a real example.  I maintain a package that can link
> with a combination of many libraries:
[...]
> The user does not need to install *all* these libraries (some of
> them do the same work) ; ./configure will just make a choice
> between what is installed.  
> 
> In order to build `./configure' you need a macro to detect each
> library.  Most of them install such a macro in /usr/share/aclocal/.
> 
> However I *do* ship these macros with my package.  This allows
> anyone who want to make a new release to regenerate ./configure.
> If I didn't, user would have to install all these (otherwise
> unused) libraries just to rebuild ./configure.

I can definitely understand why your situation makes it desirable to
include these macros in the package, but that isn't always the case.
That's why I suggest making the behavior configurable.

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