I have just upgraded to Autoconf 2.59, Automake 1.95, and Libtool 1.5.14. Now when I build shared libraries, they don't have the .so extension in thier names. Anybody know why? It may be a question for the libtool list, but I thought I try both places. Stan >>> Hugh Sasse Staff Elec Eng <hgs@xxxxxxxxx> 3/1/2005 7:39:11 AM >>> On Tue, 1 Mar 2005, Stepan Kasal wrote: > Hi, > let me formulate a proposal. I try to be as specific as possible. Thank you, this is a help (I'm somewhat overloaded at the moemnt). > > AC_MSG_NEED(PACKAGE, TEXT) > ------------------------------ > Prints a message and saves it for later usage. > Example: AC_MSG_NEED(foo, [grab the latest foo from foo.org]) > prints: > > Suggestion: > foo grab the latest foo from foo.org > This encapsulates the ideas well, > AC_MSG_COND_NEED(CONDITION, PACKAGE, TEXT) > ------------------------------------------ > Prints a message and saves it for later usage. > Example: AC_MSG_COND_NEED(--with-graphs, libxy, > [use the latest xy library from http://www.xylib.net/]) > prints: > > Suggestion (for --with-graphs): > libxy use the latest xy library from http://www.xylib.net/ > and this incorporates requirements information well. > > AC_OUTPUT Maybe call it AC_MSG_OUTPUT to tie it to the other two? > --------- > If there were any call to AC_MSG_NEED or AC_MSG_COND_NEED, all the > suggestions are printed, and then configure exits; it doesn't create > config.status in this case. > > Example: > Suggestions: > foo grab the latest foo from foo.org > bar grab the latest bar from http://www.barbar.com > (for --with-graphs): > libxy use the latest xy library from http://www.xylib.net/ > > Thats all. I think implementing this proposal is a good step forward. Yes, that is what I was hoping for. > > The most difficult part is the documentation, of course. I don't > volunteer for it. Hugh, could you please write a patch to autoconf.texi, > which would document these macros, and, most importantly, encouradge > their usage? I'm not familiar with the layout of the CVS base, so can you tell me how to get hold of the file I should be writing the patch against, please? > > I could then add some macros and patch autoconf's own configure.ac. > > A few comments: > Comment #1: > ----------- > I chose AC_MSG_NEED instead of a combination of AC_MSG_END and > AS_SUGGEST_STRING. I think the macro should be as simple as possible, > so that mor people use it. I'm happy with either, as long as something happens. Are you one of the maintainers? (I don't know "who's who" in autoconf, I admit!) > > Comment #2: > ----------- > This proposal doesn't handle dependencies among the requirements. > This is intentional; I think a maintainer should only specify the > list of requirements. Only sysadmins and distribution builders are > allowed to think about a "dependency tree". Also there is too much to consider when requesting that change. Furthermore, much can be achieved with the existing AS_IF macro, so I'm happy to let that go for now. Would it be sensible to allude to this when I write the doc patch, or just leave dependency matters out of the discussion? The critical change here is that failure is not immediate, and important messages appear at the end where they are likely to be seen (not lost from the scroll buffer). > In most cases, we can check for all requirements independently. > In the rare case when it is impossible to perform a check for "bar" > if "foo" wasn't found, we can use this pattern: > > # check for foo and set have_foo > if test $have_foo = no; then > AC_MSG_NEED(foo, [grab foo from ...]) > fi > have_bar=no > if test $have_foo = yes; then > # check for bar > # and set have_bar appropriately > fi > if test $have_bar = no; then > AC_MSG_NEED(bar, [grab bar from ...]) > fi Sounds reasonable, or one could use AS_IF. > > Hugh, are you willing to work on this proposal, and make a patch to > autoconf.texi? Yes, I'll try to put something together, but it will probably need to be reviewed as I'm not familiar enough with the use and abuse of autoconf. > > Stepan > Thank you, Hugh _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
