automake [Was: libhttp]

[Matt Zimmerman]

On Sat, Sep 22, 2001 at 11:46:54PM -0700, Ian Zimmerman wrote:

> Matt> Derived files should only be placed in the build tree, not the
> Matt> source tree, since they are usually specific to the architecture
> Matt> and configuration being built.  
> 
> But this is far from universally true.  Even the GNU manuals talk
> about including some architecture-independent derived files (for
> example, info files, yacc and lex output) in the tarball.  And this is
> the only case where you'd need to "decide" if you ought to symlink or
> not.  Quite simply you symlink everything that comes with the
> distribution, and only that.

It sounds like both approaches have the same special case to deal with.  But
what if your lex build rule looks like:

.l.c:
	-rm -f $@
	$(LEX) $< && mv lex.yy.c $@

Then the symlink is removed, and $@ ends up in the build directory.  And
what if the .c file doesn't exist in the source tree (say, because you just
checked it out of CVS)?  You still have to symlink it, so you still have to
keep a list of symlinks that need to be created.

> Matt> If the file is something that you ship with the distribution, it
> Matt> will be in $(srcdir).  If it's something that is created as part
> Matt> of the build process, it will be in "." (or a path relative to
> Matt> the current directory or $(top_builddir).  (autoconf)Build
> Matt> Directories should probably say something along those lines, but
> Matt> doesn't.
> 
> Please do not imply RTFM.  I have, many times.

Take it easy.  Read it again; I pointed out a deficiency in the manual, not
in you.

> The problem is that the distinction you make is not clear cut.  Files like
> the ones I mentioned above (derived files shipped with the distribution)
> _can_ be rebuilt if the user tries sufficiently hard, and that rebuilding
> can involve a complicated chain of pattern rules.  It is the intermediate
> files of these chains that fall in the grey area. 

It seems as if these files are rebuilt in the source tree, rather than the
build tree.  I assume this is so that they are preserved when the build tree
is wiped out.  So in this case, the derived files which ship with the
distribution go in srcdir.  I don't particularly like this, as it keeps me
from building using a read-only source tree in that case (e.g., mounted via
NFS).  But that problem exists with the symlink approach as well.

> itz> Also consider all possible interactions with .PRECIOUS,
> itz> .INTERMEDIATE, .SECONDARY etc.  Are you sure you really
> itz> understand them?
> 
> Matt> These are GNU make features, and as far as I can tell, they
> Matt> don't have anything to do with automake.  I can't find any
> Matt> references to them in any Makefile.in's generated by automake in
> Matt> my packages and projects, either.  I haven't ever used them in
> Matt> my projects, and I was only familiar with .PRECIOUS.
> 
> So you probably end up with garbage intermediate files and have to
> clean them up with the clean targets.  I try to do better, and so I do
> use these gmake features.  So, if I use automake (which forces
> srcdir/builddir + VPATH on me), I have to worry about their
> interaction with that.

No, I haven't had a problem with that so far.  For procedures which automake
understands (such as lex and yacc modules), everything just works.  The
correct files are included in the distribution, and the correct rules go in
the makefiles to rebuild them as desired.

If you are using your own implicit rules, then you must tell automake
explicitly which files should go in the source distribution (using
EXTRA_DIST or the like), and use $(srcdir) where appropriate.  If your
intermediate files are going to be removed (e.g., if they are listed in
.INTERMEDIATE), it doesn't matter in the end where they reside temporarily.
Personally, I would leave them in the build directory, to allow for a
read-only source tree as far as possible, and because that is where I would
expect them to go.

Have you ever had a concrete problem where automake's rules interacted badly
with .INTERMEDIATE and such?  I'm having trouble imagining one.

> I would like to end this thread, which is becoming too flame-like, by
> conceding that automake "works" in the sense that "sh configure ; make ;
> make install" will give users that compiled package, if that's what they
> want.  For me as a programmer, and for users who want to tinker around (as
> I do when I wear the user hat), automake imposes certain inconveniences; I
> think the use of symlink-forwarding (which I _know_ also "works", except
> for the few crippled host systems without symlinks) avoids these.  It
> probably imposes other inconveniences that I am not aware of yet, such is
> life.

For me, as a programmer, I value the tools that automake gives _me_, like
its "dist" and "distcheck" targets.  I don't know much about its history,
but I doubt that VPATH exists solely because some systems don't support
symlinks.

I'm certainly not going to try to convince you that automake is right for
you if it isn't, but it works well for some people.  I'll agree not to post
anything further on this subject.  You can have the last word if you like.

-- 
 - mdz