Re: [Opengrads-devel] dynamic supplibs checking

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

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