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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
