Martin> ftp; get foo-1.9.tar.gz; gunzip; tar xf;
Martin> cd foo-1.9; configure; make; make install
Martin> login to other machine
Martin> cd foo-1.9; configure; make; make install
Martin> # Phew! That was easy!
Tom> This only really works if you generate a config.h and you are
Tom> lucky. If an intermediate object is lying around which needs to
Tom> be rebuilt, but whose ancestors are not touched by configure, you
Tom> are screwed.
Martin> It's true. But all C source files should #include <config.h>,
Martin> and other files will often be architecture-independent files
Martin> like lex&yacc files.
That's true for XEmacs, maybe, but it isn't true for the world. For
instance, some people don't use AC_CONFIG_HEADER. Or, more
compellingly, Java programs compiled with gcj generally won't rely on
config.h or any other configure-generated file -- but will still leave
objects lying in the build tree (see libgcj for an example where the
majority of actual object files are not affected by configure's
output).
Basically, the user really does have to run "make distclean" between
configures on different machines. It can work sometimes, for some
packages, but that is by no means universal. Users who rely on this
are just doing the wrong thing.
Martin> By the way, one of the programs I'm most proud of is the
Martin> accurate C source dependency generator for XEmacs - it's
Martin> src/make-src-depend - a perl script (does that match Akim's
Martin> expectations of emacs maintainers)?
Could you email it to me?
Tom
