Re: AMLOCAL_AMFLAGS and the dist recipe

[Ralf Wildenhues]

* David Byron wrote on Wed, Nov 16, 2005 at 04:37:45PM CET:
> On November 15, 2005, Ralf wrote:
> 
> > First idea: In the directory, where aclocal searches by
> > default ($prefix/share/aclocal, usually), edit/create the
> > file `dirlist' to point to the directory your macros are in.
> > Then, #2 will work without any ACLOCAL_AMFLAGS.
> 
> I could see this working, but then I need an absolute path to the
> directory where my macros are

No, you don't.  Not in the package, at least, unless I still
misunderstand you.

Say, you have $HOME/my_macros/foo.m4
and you want to use them in $HOME/my_codes/configure.ac
and also your Automake was previously installed in /usr/local,
then you put the line
  $HOME/my_macros
(with $HOME expanded) in
  /usr/local/share/aclocal/dirlist

and then aclocal will find them.

> ...My reflex is still for each person who
> grabs files from revision control to have his/her own copy of the
> scripts, so someone working on them doesn't break them for everyone
> else.

Sure.

> > OTOH having one file per macro is much nicer: Why not
> >   mkdir m4
> > add `ACLOCAL_AMFLAGS = -I m4' to Makefile.am
> > add `AC_CONFIG_MACRO_DIR([m4])' to configure.ac?
> 
> I don't see how this is one file per macro.
> 
> Also, I'm not using AC_CONFIG_MACRO_DIR at the moment, but things seem
> to work.  Can someone enlighten me here?

Kind of a future thing.  Not all autotools support this fully yet.

> > and with CVS Automake you could simplify that to
> >   aclocal --install -I m4
> > (or add `ACLOCAL_AMFLAGS = -I m4 --install' to Makefile.am and have
> > autoreconf run it for you).
> 
> This last suggestion seems pretty similar to the way I've got it working
> now, except that instead of getting the autotools to copy the macros for
> me, I copy them myself.  I agree it's cleaner to have them in an m4
> directory instead of as part of aclocal.m4, but not cleaner enough to
> make it worth maintaining a bootstrap script...or at least it doesn't
> seem so at the moment.

OK.

> > > The other small downside to this solution is that instead of
> > > just sharing the macros as they are in the tree of files
> > > from revision control, they get compiled into aclocal.m4 in
> > > each project that uses them.
> > 
> > Yes.  I'd not put them in revision control, though.  But
> > this issue (whether to store generated files there) is
> > controversial, and there are arguments for both sides.
> 
> I also try to avoid storing generated files in revision control.  I'm
> not sure what files you mean though.  My macros foo.m4, etc. aren't
> generated files as far as I can tell.

Well, from a certain standpoint: in the packages you _use_ them, they
are generated (copied from somewhere else).  Not in the one where they
originate.

Regarding the issue whether to put them all into aclocal.m4 or into
separate files below m4/: Recent aclocal versions will generate a bunch
of
  m4_include([m4/foo.m4])
statements (if you choose to 'aclocal -I m4'), so there is less macro
code duplication.  I find updating easier if the macro files correspond
to each other.

Cheers,
Ralf