RE: AMLOCAL_AMFLAGS and the dist recipe

[David Byron]

On November 17, 2005, Ralf wrote:

> * 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.

OK, so that keeps my $HOME/my_codes/* clear of absolute path references,
but then I have to maintain a dirlist file.  Not the end of the world I
suppose, but I think it means all developers are sharing the macros in
one developer's working directory...In other words, it's possible for
one person to break everyone else's tree, which I'd like to avoid.  I
could keep a "good" copy of the macros somewhere, but that's another
thing to maintain.

> > > > 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.

Good point.  I'm not storing aclocal.m4 in revision control.

> 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.

I think this gets me back to the beginning again.  I prefer
m4_include(m4/foo.m4) to having the macros copied into aclocal.m4 as
well.  But, then make dist doesn't work.

My original two cases were:

1. ACLOCAL_AMFLAGS = -I ../../scripts/m4

or

2. ACLOCAL_AMFLAGS = -I `cd ../../scripts/m4 && pwd`

I think #1 is cleaner because of m4_include and because there's no shell
magic, but make dist is broken.  You've given me some good alternatives,
but I'm spring-loaded strongly enough towards keeping all the code trees
independent that I'm going to stick with #2 for now.

I don't know enough about automake/aclocal to know if a patch there to
fix make dist for #1 is feasible.  I'll give it a shot if folks think it
makes sense.

Thanks for your help.

-DB