On Thu, 24 Feb 2005, Dan Manthey wrote:
On Thu, 24 Feb 2005, Paul Eggert wrote:
Dan Manthey <dan_manthey@xxxxxxxxxxx> writes:
AS_PACKAGE_SUGGEST([flex 2.5.x],[http://gnu.org/whereever_flex_is.html])
OK, but what is the practical difference between that, and something like this?
AC_MSG_FAILURE([you need a suitable implementation of "lex" to build this package. We suggest the latest stable version of flex <http://www.gnu.org/software/flex/>.])
Hmm, the Autoconf doc PDF doesn't explicitly say what this macro does, only describing how it is used. Does it cause processing to stop? I don't want processing to stop.
I was thinking of AS_PACKAGE_SUGGEST (which I'm sure is a bad
AC_PACKAGE_RECOMMEND, maybe, if it SUGGEST sounds too weak??
name) as simply a formatting macro. It might be reasonable to have it as a macro rather than simple next because it might allow collecting all such messages into a single place (like the putative DEPENDENCIES file
which collection is what I'd like, and the other 5 people on gnu-prog-discuss.
discussed).
my_warning='you lack a suitable implementation of "lex", so you won't be able to build this program reliably if you modify .l files.'
and then append something like this to your configure.ac file:
case $my_warning in ?*) AC_MSG_WARN("$my_warning");; esac
I figured this would basically be what AC_MSG_END would do, except possibly push it off to a file rather than a variable, in case the contents were large (which seems more likely if the errors include long explanations of what kind of package is needed and where to find it).
and a file allows accumulation of information, and facilitates formatting with fmt etc, if desired|portable...
Also not having to explicitly write the case statment is good: "code you don't write doesn't have bugs" as someone pointed out on Ruby-Talk.
An advantage of this sort of approach is that one can experiment with these ideas now, to accomplish something in this area. That is, one
People have said that some packages already do this to some extent.
can implement them with one's own macros; they don't require any changes to Autoconf. Later, if the ideas work well in practice, we can think about how to add Autoconf macros for them (perhaps simply by incorporating the experimental macros).
Indeed, though it is worth noting that sensible use of these ideas may be dependent on conditional tests, which I don't think Stepan's AC_DEFUN'ing AC_IF quite solves (as helpful as it is as an interim solution). It looks like Hugh would _strongly_ desire an actual macro AC_MSG_END (even if it's as simple as Paul's code above) for the simple fact that it would encourage use of such messages.
Yes, for that reason. I'd also like it to be a recommended
practice. Maybe not SHOULD, or MUST, but recommended, because I have spent so long trying to find out what I need with packages,
running configure scripts more times for a give package than I care
to remember! And someone else referred people to
http://www.pdc.kth.se/~jas/one-long-torture.html
as an exmaple, which doesn't describe how they managed to find out what worked. I don't know how to get things recommended for autoconf practices: GNU coding standards, autoconf docs or somewhere else?
-Dan
Thank you,
Hugh_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
