Re: [Opengrads-devel] dynamic supplibs checking

[Jennifer A. <jm...@co...>]

One thing needs clarification in the logic.

--enable-dyn-supplibs    never look for "supplibs" and always use DYN  
macros to look for libraries
--disable-dyn-supplibs    always use "supplibs" and never use DYN  
macros to look for libraries

The problem is that neither of these represents the default behavior,  
which is to use "supplibs" first and then use DYN macros to look for  
libraries not in "supplibs". Maybe we should have two enable/disable  
flags, one for looking in "supplibs" and one for using DYN macros,  
both of which are on by default. The thing is, the --enable-supplibs  
flag would be redundant if you set up a "supplibs" directory in the  
first place since it will not exist by default. If the user goes to  
the trouble to set up "supplibs", I guess it's safe to assume we  
should use those libraries instead of system versions, unless  
otherwise directed. So maybe the two options above are what we need,  
even they don't really represent a yes/no flag.

Jennifer



On Aug 1, 2008, at 9:59 AM, Jennifer Adams wrote:

>
> On Aug 1, 2008, at 8:55 AM, Patrice Dumas wrote:
>
>> On Fri, Aug 01, 2008 at 08:09:12AM -0400, Jennifer Adams wrote:
>>> Dear Experts,
>>>
>>> I've been pecking away at the configure scripts and thinking about
>>> the
>>> logic in them. There's a lot of cruft in there -- support of
>>> "historical" stuff that is no longer relevant, and outdated platform
>>> dependencies.
>>
>> Do you see that in configure.in/acinclude.m4 from, for example,
>> grads-2.0.a2, or in the macros used with --enable-dyn-supplibs in
>> opengrads?
> The cruft I'm talking about is anything related to the CRAY, support
> for the "wi" command, directory names called "supplibs-sol55", stuff
> like that.
>
>> I don't see that in configure.in/acinclude.m4. It is
>> present in opengrads, but it is not an issue, in my opinion. On the
>> contrary, it allows to build grads against old libdods, for example,
>> which is possible and should not be dropped in my opinion.
> I don't want GrADS 2.0 to keep trying to support libraries that
> depend on old versions of other libraries and compilers. My remedy
> for GrADS's bad case of versionitis is to forget the past and make it
> work with current versions of the dependent libraries. For example, I
> need to make sure I've got HDF4 built with the --disable-netcdf
> option, and that option is working properly in HDF4.2r3 (this version
> has finally eliminated all dependence on netcdf.h  -- oh, If I had a
> dollar for every pain that netcdf.h has caused me ... I'd get a free
> lunch!) The whole DODS mess is the worst offender. libgadods, libdap+
> +, libnc-dods, RIP.  Can't wait till libnc-dap.a is swept up into
> libnetcdf.a.
>
>> Also those
>> macros in fact come from other sources and should be kept  
>> synchronized
>> with these sources (mostly opendap).
> The dyn-supplibs macros are the ones I want to bring into the GrADS
> mainstream, to be used by default.
>
>>
>>> It seems to me that the default behavior should be to look
>>> for a directory called "supplibs" (in ./ and ../) and if not found
>>> then
>>> go hunting in the system for the required libraries, creating a
>>> dynamically linked executable. To create a more portable build, the
>>
>> Does this means that --enable-dyn-supplibs is the default unless a
>> ./supplib or ../supplib directory exists, and if a ./supplib or ../
>> supplib
>> directory exists one has to add --enable-dyn-supplibs to link against
>> system libraries? It it is what you meant, this seems reasonnable
>> to me.
>
> I want ./supplibs to be the first place to look for libraries, then
> if they don't exist there, go hunting for them in the system. If a
> user knows where a library is, but it's not in ./supplibs, then the --
> with configure flag is used to guide the hunting.
>
>>
>>> configure flag "--disable-shared" will stick with what's in the
>>> "supplibs"  directory and use the "-L/ga_supplb_path/libname.a"
>>> syntax
>>> instead of -L/path -lname" .
>>
>> That is not clear to me. What would the difference be between a build
>> with "--disable-shared" and a build with a ./supplib or ../supplib
>> directory present would be?
>
> You're right, there would be no difference if "supplibs"  always
> trumps the system location. I guess the --enable-dyn-supplibs flag
> could disable the check for ./supplibs or ../subblibs and then system
> location would trump "supplibs".
>
>>
>>> The "--with-PACKAGE" configure options will
>>> be used to guide the hunting for a specific library, something like
>>> --with-hdf=/opt/local (and then it will look for
>>> /opt/local/lib/libmfhdf.a and /opt/local/include/mfhdf.h)
>>
>> Agreed. It could even be used to use some supplibs but not all.
>> --without-* could still be used to disable a feature.
>
> Yes, the --without flag could save configuration time if you don't
> care about enabling a certain feature. The HDF group has a nice model
> for configuration with dependent libraries. I am going to borrow some
> stuff from them and separate out each library that is required. I'll
> look for libz.a, if not found, I can skip looking for a lot of other
> libraries (png, gd, hdf, grib2). If I do find it, add it to my list
> of libs and includes and continue, enabling features as I go through
> the list of libraries.
>
>
>> I don't understand clearly, however, if you want to use the same
>> macros
>> to detect the system libraries and the supplib libraries. If it is  
>> the
>> case it won't be that easy to achieve, because linking staticaly
>> against a supplib means supplying the path of the static
>> library or enclose the static link in -Wl,-static -lname -Wl,-dy (for
>> gcc, at least). This wouldn't easily be done with the system library
>> detection macros.
> Hmm.  Let's consider the readline case. Current code is :
>
>    if test "$ga_dyn_supplibs" = "yes" ; then
>      GA_LIB_READLINE([use_readline=yes readline_libs=""])
>    else
>      GA_CHECK_READLINE([use_readline=yes])
>    fi
>
> What if I changed that to something like:
>
>    if test "$ga_dyn_supplibs" = "yes" ; then
>      GA_DYN_READLINE([use_readline=yes readline_libs=""])
>    else
>      GA_SUPPLIBS_READLINE([use_readline=yes],[use_readline=no])
>      if teset "$use_readline" = "no" ; then
>        GA_DYN_READLINE([use_readline=yes readline_libs=""])
>      fi
>    fi
>
> Where GA_SUPPLIBS_READLINE only looks in ./supplibs and always uses
> the static link -L/supplibs/libname.a
>
> Would that produce the desired result?
>
> Jennifer
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel

--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...