On Wed, 15 May 2002, Mark D. Roth wrote:
> > I think "aclocal" pretty much does what you want.
> > E.g., "aclocal --print-ac-dir", and "aclocal -I DIR".
aclocal has good intentions, poor design.
> 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?
;-)
> 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?
there's nothing to stop - but my point: the given approach makes it less
likely that someone will be able to easily get the macros since they're
in a site-specific somewhere-else. I've seen far too many crappy packages
built with the automake scheme where I cannot find the associated macros.
--
T.E.Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net
