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

[Stepan Kasal]

Hello Hugh,

On Thu, Mar 03, 2005 at 05:38:54PM +0000, Hugh Sasse Staff Elec Eng wrote:
> >>>"I suggest you to install package foo, which can be grabbed from foo.org,
> >>>in order to proceed with this build."
> >>
> >>Ouch.  That's not how I interpreted your output.  Perhaps we should
> >>rethink the output format.
> >
> >definitely.  That's part of the work I hope Hugh will do for us.  ;-)
> 
> Yes, I'll do what I can but now I'm rather confused as to what has
> reached concensus.

There is no exact consensus.  You are changing the world, by choosing
from the proposals.  The details can be discussed later.  ;-)

I believe there is a consensus that configure should not stop on
first missing prerequisite.  It should list all missing prerequisities
at the end.  So your document should teach people to write configure.ac
in a way that this is achieved.

I believe there is no consensus whether configure should try to handle
dependencies between the individual prerequisities.  So in this
iteration, think about "list of prerequisities of the package",
not about any type of "tree".

So the main goal is to explain people that, in most cases, it's not
good to stop the script by AC_MSG_ERROR.
Instead, a message like
        "You should install XYZ to provide libxyz."
is to be displayed either immediately or in a summary at the end, or
(my preference) at both places.

The actual way to achieve the behaviour is not clear now:
- I'm for more specific macro which would presumably get more
  acceptation (AC_MSG_NEED)
- Paul is for more general macro, like AC_MSG_NOTICE with two
  arguments.  (But if we want to trace this macro, in order to grab
  the requirements, we might need a second macro, an analogy to
  AS_HELP_STRING, for more formalized suggestions.)

You can select any of the two approaches here.  It should be easy to
switch to the other method if we decide to.

The main goal is to have nice doc, which will convince people; macro
definitions can be adapted, in order to get the doc cleaner.  ;-)

> [...] and (b) allows messages at the end.  So it's really just (b)
> and documenting its use with AS_IF.

I would say it's only (b).
Your text shouldn't explain anything about AS_IF.

I even think that your examples should use `if', not AS_IF, because
many people know shell programming, and AS_IF would scare them.

The subtle problem with AC_REQUIRE, which is solved by AS_IF,
doesn't happen so much.  And in the long term, autoconf-3 will use
functions and AS_IF will no longer be necessary.

But again, pick any of the two alternatives for now, it's not the
central problem.  Just don't waste time by writing an explanation
of AS_IF, it doesn't belong here.

> now a list of priorities, which I don't fully understand.

Let's say that
        AC_MSG_NOTICE([blah blah], 0, 7)
could display the message both immediately (the 0), and at the end
(with priority 7).  Use this feature or not, according to your taste.
We will implement something like this, if it will be needed.

> We also have proposals about AC_MSG_ERROR and AC_NONFATAL to affect
> where configure creates a config.status message.  I think I'll need
> to document which variables are to be included in such code, even if
> the code is written after.  The manual is for developers, after all.

Let's recall is that config.status is the "worker script" which
actually does all the substitutions, ie. creates config.h and all
the Makefiles.  

At the end of its run, ./configure creates ./config.status, and then
runs it.  (This code is the expansion of AC_OUTPUT.)

If the requirements are not met, we shouldn't create Makefiles.
So my proposal was that if there are some missing requirements
accumulated, AC_OUTPUT displays them, and ./configure exits;
otherwise, AC_OUTPUT proceeds (creates and runs config.status).

Most of your text will probably go to the node describing
AC_MSG_NOTICE.  But you'll also have to add a sentence and an xref
to the description of AC_OUTPUT.

With this scenario, I see no need to document the internal variable
used by autoconf in order to achieve this.  But again, this is a
detail which can be changed later.


Hugh, I'd like to thank you.  I'm very glad that you are still willing
to contribute, even though the grand plan of "DEPENDENCIES.xml" has
evolved into a small first step: "messages at the end + document the
best practice".  I'm thankful for your help, because I'm sure that
this first step is a good and important one.

Thank you,
        Stepan Kasal