Re: [Opengrads-devel] dynamic supplibs checking

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

On Aug 1, 2008, at 11:20 AM, Patrice Dumas wrote:

> On Fri, Aug 01, 2008 at 09:59:33AM -0400, Jennifer Adams wrote:
>>
>> 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.
>
> Right. Indeed, those things can certainly go away. Though they are not
> really problematic either.
>
>>> 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.
>
> I disagree with that view. I think that the automatic detection of
> libraries should try to find any compatible library, to leave to the
> user the choice of the libraries. Of course, to ease maintainance very
> old cruft should be removed, but, for example, the --disable-netcdf
> option has varied a bit from 4.2r1 to 4.2r3, and my point of view  
> is that
> all those versions should be usable if the burden is not too high. In
> RHEL4 the hdf version is still 4.2r1 and will certainly remain as is
> until the end of life of RHEL4 which is Feb 2012, and it would be nice
> for the maintainer of grads in EPEL4 (who happens to be me, for the  
> time
> being, but who knows in 4 years) if grads in 2012 could still use  
> 4.2r1
> unless there has been technical reasons not to use it anymore. There
> could be very valid reasons not to use 4.2r1 but if there is not it is
> better to be able to use it in my opinion. The RHEL4 example is not
> necessarily a plea for having grads still build on RHEL/EPEL4 in 2012,
> but an indication that some users want to be able to use a stable
> system, and I think that these users should be taken into account, as
> long as it doesn't cost too much.
Very persuasive. I guess it depends a lot on which libraries we're  
talking about. It's not fair to lump HDF into the same category as  
DODS, which is far more aggravating to support. But if you have an  
old box with gcc 2.95, you just can't have an opendap-enabled build  
of GrADS 2.0.


>> 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.
>
> Ok, I have understood now. It certainly covers the grads users need.
>
>> 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".
>
> If I understand rightly what you said in the other mail, it would  
> become
>
> * no args to configure:
> search in supplibs and, if not found, use system libs.
> * --enable-dyn-supplibs
> never search in supplibs, even if the directory exists
> * --disable-dyn-supplibs
> never use system libraries
>
> Did I got it right?
Yes. It's a little unorthodox, but it achieves what we need.

>
>> 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
>
> Not only, also build time, and could allow for disabling features. One
> may not want the support for some formats for security reasons, for
> example.
>
>> 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'd say that speed doesn't really matter, what matters is the
> maintainability of th ecode and the correctness of the results.
>
>> 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?
>
> It looks good.

OK. I will get back to reworking some of this code and write again  
when I am stuck.
Jennifer

>
> --
> Pat
>
> ---------------------------------------------------------------------- 
> ---
> 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...