automake [Was: libhttp]

[Ian Zimmerman]

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.

Matt> What other complications are you referring to?

itz> I remember when I stopped using automake: I was trying to decide
itz> whether to use $(srcdir) or not in a given dependency.  I thought
itz> for minutes and minutes, and couldn't figure it out.

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.

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. 

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.

Matt> All intermediate files go in the build directory.

See above.  

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.

-- 
Ian Zimmerman, Oakland, California, U.S.A.
Hypocrisy, arrogance and manipulation: sure-fire ways to earn hatred.
GPG pub key: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087