>>>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Martin> The config,cache is friendly mostly to Cygnus employees,
Martin> hostile to everyone else. Let's optimize for the newbies, not
Martin> the pros.
Tom> I don't disagree. I like Alexandre's idea of enabling it only when a
Tom> cache file is specified on the command line. I don't like other ideas
Tom> I've heard in the past, which involve editing configure.in; that leads
Tom> to random, meaningless divergence in gcc-like trees.
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 lucky.
Tom> If an intermediate object is lying around which needs to be rebuilt,
Tom> but whose ancestors are not touched by configure, you are screwed.
It's true. But all C source files should #include <config.h>, and
other files will often be architecture-independent files like lex&yacc
files. So a `normal' build tree should already be pretty close to the
ideal. In fact, you can think at a higher level. Any file that is
system-dependent will depend on a system description file like
config.h, and that will be touched by configure. So if (yes, a BIG
if) the dependencies are accurate, everything should just work.
Tom> But the cache, or something like it, is the way to solve this problem.
Tom> If you record system info in the cache, and notice when it is wrong,
Tom> you prevent the strange errors.
But the system info you need to record is all the information you're
caching. The only way to tell if the sysadmin has installed libxpm is
to test for it. You can't rely on the value in the cache. Other
system variables are less volatile, but it's only a matter of degree,
not kind. Certainly, you'd have to record the configuration triple,
the compiler version (not just the compiler itself - the binary could
have been upgraded), the compiler flags, system header file updates,
system library updates, even user variables like a new setting for
LD_RUN_PATH, and all those variables like CC, CFLAGS, LIBS, ....
Maybe someone fiddled with the compiler spec file. Maybe the sysadmin
didn't change any files, but merely ran ldconfig after forgetting for
a few months?
In the end, the only way to tell if the current system has a usable
libxpm installed is to try a compile and a link. No way around it.
Tom> Or are you talking about machines where, say, config.guess prints the
Tom> same thing but where libraries and other things are installed in
Tom> different places? I don't see how removing a config.cache helps here,
Installed in different places on the _system_, not in the build tree.
Tom> really. You can still have incorrect intermediate objects in the
Tom> build tree, screwing the naive user. At some point they have to read
Tom> the directions.
All system-dependent intermediate objects should depend on the system
information files generated by configure.
Although it is true that makefiles are universally broken (and I won't
try to hold up the XEmacs build process as a shining example of
virtue) we should demand more from the package maintainers than the
package builders and installers. A carefully written package, with
natural machine-maintained dependencies, will do the right thing after
a reconfigure;make on a different machine.
Of course, it goes without saying here that a careful user will always
rm -rf;tar xzf
to create a new pristine tree to build and install. We all do that, right?
Dirty trees are only for hacking. But we should try to do the Right
Thing even when the user is careless.
By the way, one of the programs I'm most proud of is the accurate C
source dependency generator for XEmacs - it's src/make-src-depend - a
perl script (does that match Akim's expectations of emacs maintainers)?
