For whatever it's worth, it's possible for different systems (or different
versions of libraries) to lay out their functions in different libraries.
So often the point of a library or function check is to pull in a library if
it exists on that system (or if the desired function is in that particular
library.) And if the library doesn't exist, it isn't necessarily always an
error. Depending on the layout of a particular system, we certainly
wouldn't want to link against a library that doesn't exist. The autoconf
check can account for this.
The automake/autoconf system could always use more love (can't we all?) :-)
but let's be careful and proceed with a good understanding of all the
nuances.
Curt.
On Mon, Feb 8, 2010 at 3:12 PM, Jari Häkkinen <j...@flygarna.se> wrote:
> On 2/8/10 6:58 PM, Geoff McLane wrote:
> > As you have read, I have suggested that we abort
> > during the configure step in case of this 'no',
> > for this important library, but that is only a
> > 'choice'.
> >
> > If the person 'sees' the 'no', says oops, and does
> > something to fix it, like install the OSG libraries
> > in a 'standard' place... then there is no reason to
> > have aborted the configure step... and they can
> > continue with make...
> >
> > But I agree, it does seem better to abort, but not
> > essential.
>
> I think it is helpful to actually report potential problems found in the
> end of the configure script. For each important 'no' found a flag can be
> set and in the end of the configure script a warning message AC_MSG_WARN
> (or a fatal message AC_MSG_ERROR) can be displayed to inform the user
> that there are unresolved issues. The problem is that there are quite a
> few 'no's that are not fatal and for newcomers to fg/sg it is not easy
> to understand which 'no' to ignore.
>
> Personally I keep track of failed checks and report them in the end of
> my configure.ac's. I even conclude with printing all important variables
> like
>
> # Some more messages.
> AC_MSG_NOTICE([
> Ready to compile the executables of svndigest $VERSION
> The following flags and libs will be used:
> +++++++++++++++++++++++++++++++++++++++++++++++
> Compiler: $CXX
> Preprocessor flags: $SD_CPPFLAGS $CPPFLAGS
> CPPFLAGS: $CPPFLAGS
> DEFAULT_CPPFLAGS: $DEFAULT_CPPFLAGS
> APR_CPPFLAGS: $APR_CPPFLAGS
> SVN_CPPFLAGS: $SVN_CPPFLAGS
> PLPLOT_CPPFLAGS: $PLPLOT_CPPFLAGS
> C++ flags:
> CXXFLAGS: $CXXFLAGS
> DEFAULT_CXXFLAGS: $DEFAULT_CXXFLAGS
> Linker flags:
> LDFLAGS: $LDFLAGS
> APR_LDFLAGS: $APR_LDFLAGS
> SVN_LDFLAGS: $SVN_LDFLAGS
> PLPLOT_LDFLAGS: $PLPLOT_LDFLAGS
> Libraries:
> LIBS $LIBS
> APR_LIBS $APR_LIBS
> SVN_LIBS $SVN_LIBS
> PLPLOT_LIBS $PLPLOT_LIBS
> +++++++++++++++++++++++++++++++++++++++++++++++]dnl
> )
>
> and I even end with
>
> AC_MSG_NOTICE([Now type 'make all check'.])
>
> to indicate what the user should do next. Of course, any fatal failures
> will make configure to not display the last message.
>
> sg/fg configure.ac is not providing the above service (sg/fg does print
> some final messages) is not a bug but could be added to some list as a
> feature request.
>
>
> Cheers,
>
> Jari
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
