Re: installation instructions on OpenBSD and FreeBSD

[Marc Espie]

On Fri, Mar 16, 2001 at 01:16:10AM -0500, Greg A. Woods wrote:
> 
> Strictly speaking such systems as the *BSD ports/pkgsrc should not be
> running the configure but should instead have pre-canned configurations
> ready to use.
> 
> Configure is just too damn smart for any package building system,
> particularly when the goal is to build binary installable packages!
> Configure ends up having very bad SCM hygiene in these scenarios.
> 
> Unfortunately building canned configurations that are adjustable in
> minor ways (eg. path prefixes, etc.) is very hard to do.  Perhaps if
> Autoconf offered some way to build intermediate configurations that
> still allowed some further configuration to be done at a later time then
> things would be a bit simpler to manage.

Simply put, configure is missing some high-level meta-information about
what it's trying to do.
When you look at the output, it's blabbing away, but due to the way 
tests are structured, you don't even see all the things it could be
testing.
If there was a high-level file really stating what it's trying to test for
and, more importantly, a way to individually set each characteristic before
running configure (e.g., disable some features), we wouldn't be in
trouble... and I don't mean the configure.cache, which is already at too
low a level to be any use.
There ARE a few tests which are overrideable, like the test for bison.
Unfortunately, most variables for such tests are hard to guess for, and
you must read the configure.in file for them, which is hard to do for
profane users.
Say, a config.template that would look like:
look for yacc= [auto]
look for pcre= [auto]
gimme a awk  = [auto]
look for ossaudio= [auto]
...

and then you could pass a partially instantiated file to it:
look for yacc=          no
look for pcre=          no
gimme a awk=            [auto]
look for ossaudio=      present
...


or something like that (incidentally, this would give us a way to simply
circumvent broken tests in cases where we know what should work, like
xterm-152 forgetting to #include <Xlib.h> in its freetype test, or squeak
failing the ossaudio test because it can't run /usr/bin/test...)

The other thing that would help would be to have more complete test bases,
that were publicized, and updated very frequently, compared to the core
of autoconf, so that most people wouldn't have to ship aclocal.m4 files,
because the stuff in there is often poorly tested, and propagates in weird
ways, which means that you often get to fix the same bug 10 times, because
it propagated from one program to the next one, even though the bug has
been integrated and fixed in the main autoconf CVS repository six months
ago.