h a l f b a k e r yTip your server.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Anyone who has had to build a program
from source on a *nix operating system
has probably encountered something like
this:
checking whether build environment is
sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking
whether make sets $(MAKE)...
yes
checking build system type... powerpc-
apple-darwin7.5.0
This "checking" stage of the
configuration
process usually involves around one
hundred various tests of the system,
determining what commands are
available
to use and other environmental
conditions.
It seems that almost everything goes
through this phase, which seems very
redundant - especially if you have to re-
configure many times during
troubleshooting.
So, why not have a cache of all of the
various tests and such, quickly accessible
by any configuration script. You could of
course update the cache at any time, or
tell a specific configuration script to
ignore the cache and determine values
for
itself.
"Hello World!" example for autoconf and automake
http://www.amath.wa...lsmanual.html#SEC33
These are some of the tools that generate ./configure.in, which generates ./configure, which generates Makefile, which generates the executable. [jutta, Oct 11 2004]
[link]
|
| |
In general, what you're calling for is a good thing. While installing something new, it should be easy to change parameters, and the system should quickly, and meaningfully, react to those changes. |
|
| |
The "./configure" script that ships with much modern Unix software (and which is responsible for the lines you qoute) already caches its configuration (in a file config.cache). It shouldn't be too hard to extend the notion to a global configuration default file shared between different tools. |
|
| |
One, this is already a very complicated system, with generators generated by generators etc. It is almost impossible to debug if something goes wrong in the late build phase. So, adding another layer of caching here may make something that already is ridiculously complicated just a little worse. |
|
| |
Two, the meaning of these tests isn't *quite* fixed. There's a large set of defaults that are pretty much the same in practice, but they can change across different versions of autoconf, and tools can add their own tests.
And of course two tools, developed by two people who don't talk to each other, can use the same test with different meanings.
One could work around that by explicitly distinguishing the shared from the individual variables, but as the set of shared variables evolves, there's always going to be a boundary area where meanings do change. |
|
| |