Re: RFE: configure -> dependency list on exit.

[John W. Eaton]

On  4-Mar-2005, Stepan Kasal <address@hidden> wrote:

| My idea was to have AC_MSG_NEED with args
|    (@var{dependency-name}, @var{dependency-text}, @ovar{priority})
| used like
| 
| AC_MSG_NEED([flex],
|   [Get the latest version of lex from ftp://ftp.gnu.org/gnu/flex/.])
| 
| Which would display:
| 
| You should get:
|   flex                Get the latest version of lex from
|               ftp://ftp.gnu.org/gnu/flex/.

I think I understand why you want these kinds of messages.  There have
been times when I've tried to build software and I've had to go find a
bunch of tools and some of those required other things that were not
installed, etc.  It was a hassle.  But this has not happened much
lately, as my method for installing software has mostly gone from
"configure ; make ; make install" to "apt-get install package".

Given that we now have nice packaging systems, messages like the one
you propose above are not always the best advice.  On a modern
GNU/Linux system, you would probably want to direct most people to
take advantage of the available package system instead of going to an
ftp site to download another source package.  At least on the systems
I use, the package system will generally do a better job of installing
something than I would do by hand from a source package because it
enables easy upgrades in the future.

But there is no way a person who is writing configure.in can know
about all of the various package systems available, and I don't think
it makes any sense to try to embed that kind of knowledge in
autoconf.

So perhaps it is best to just have the messages say something like

  You need the lexical analyzer flex to rebuild lex.c from lex.l.
  If your OS has a package system, you may be able to use that to
  install a recent copy.

I hesitate to add something like

  If not, then you can find flex at ftp://ftp.gnu.org/gnu/flex.

because the URL may change, and it means that either the person
writing configure.in will need to know about all these things (even
they may not have a clue where flex really comes from if they just get
it from their package system) or you have to embed this knowledge in
autoconf, which seems bad and would only work for a few tools in
autoconf which have specific macros (bison, flex/lex, ...).

jwe