On Wed May 15 17:21 2002 -0700, Paul Eggert wrote:
> I use Automake's "aclocal" for this. It generates aclocal.m4
> automatically from m4/*.m4. In my case, the m4/*.m4 files are often
> links to the "canonical" versions.
Unfortunately, that won't work for me, since I use autoconf but not
automake. Also, if I understand you correctly, this solves the
problem of keeping multiple copies in sync, but I'd still need to
manually maintain a symlink for each macro I wanted to use in the m4
subdirectory for each package. Wouldn't it be much more convenient to
have autoconf look directly in a central location, rather than
manually maintaining symlinks to the central location from each
package?
> I think "aclocal" pretty much does what you want.
> E.g., "aclocal --print-ac-dir", and "aclocal -I DIR".
It doesn't really make sense to me that I should need to install a
seperate package just to be able to use a set of macros that are
maintained seperately. If it's autoconf's job to use these macros to
generate configure, shouldn't it provide a central place to install
them?
Also, even if aclocal were part of the autoconf package, this approach
still requires special flags in order to find the locally-installed
macros. Going back to the perl analogy, would it make sense to
package up a perl module and tell the user that they needed to invoke
perl with "-I/path/to/perl/module" in order to use it? This isn't
necessary because perl knows to look in its site_perl directory, which
makes it much more convenient.
On Wed May 15 20:38 2002 -0400, Thomas Dickey wrote:
> On Wed, May 15, 2002 at 05:38:40PM -0500, Mark D. Roth wrote:
> > "${prefix}/share/autoconf/site_macros"). If one of my packages uses
> > one of these macros, I'd put a note in the README file that says "if
> > you need to regenerate configure, you'll need autoconf (available from
> > ...) and macro package foo (available from ...)".
>
> nice in theory, but in practice not (I stopped submitting patches for
> ncftp because the developer did not wish to package the macros where they
> were accessible).
No matter how autoconf works, there's nothing stopping any given
developer from making it impossible for others to use his/her
packages. With the current functionality, a developer could just
remove aclocal.m4 before making the source code available. So what do
we lose by providing functionality that makes autoconf more convenient
for people that want to do things right?
I understand that there are already ways to share macros, but what I'm
pointing out is that adding a site macro directory would do the same
thing in a much more convenient way, and wouldn't reduce the current
functionality at all. So what's the down side?
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
