opengrads-devel — OpenGrADS development issues, with focus on interfaces and extensions

Re: [Opengrads-devel] dynamic supplibs checking

[Arlindo da S. <da...@al...>]

Jennifer,

   It is a busy day for me, I haven't read the exchange in great
detail. A couple of comments,

1) The clean-up/refactoring is very welcome

2) Having a flexible build that would look for dependencies in the
supplibs and if not found look "around" sounds good in principle but
can be tricky to implement. The supplibs not only builds everything
statically, but do so cooperatively: dependencies are resolved within
the supplibs. Having the build look at the supplibs and them elsewhere
needs to be done with extreme care so that we don't ended up using 2
different versions of the external libraries.  For this reason I
always felt it was safer to either build with the supplibs exclusively
or else look around. The point is, we need to make sure that external
libraries being used are built consistently.

3) About the detection m4 macros. More and more packages are providing
tidbits of m4 macros to detect their library which we can incorporate
in our build. As much as it makes sense we should ntry to use these m4
fragments "as is" without much grads customization. This way we would
be able to upgrade it when I new version of the package are brought
in.

4) Regarding

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

I never liked the term "dynamic supplibs".  It really means, look
around for the dependencies as any other package would do - those
libraries do not have to conform to any of the supplibs conventions.
I'd suggest
something like:

--with-supplibs[=SUPPLIBDIR]        which tries to resolve the
dependencies within the supplibs
--without-supplibs                               the opposite

Now, for those cases where the user would prefer to use the system
libraries and complement it with the supplibs for those few libraries
they don't have this could be done simply with specific macros such as

--with-netcdf=include_path,lib_path

or by simply setting the CPPFLAGS, etc. I'd not try do to this
automatically: it is tricky and prone to error.

Regarding the question of defaults. Building against pre-compiled
supplibs is the easiest and more likely to produce correct binaries.
I have had very good experience with v1.9.0-rc1 and v2.0.ax.oga.y
builds. So, --with-supplibs could be the default. However, if the
supplibs cannot be found you could issue an warning:

- Cannot find supplibs; either download them from http:/.... or
specify --without-supplibs for satisfying the dependencies with
locally installed libraries.

5) Readline. One of the portabilities issues I ran into recently is
termcap/ncurses. Termcap is deprecated and recently I have added
ncurses to the supplibs, although as of yet not all pre-compiled
supplib tarballs have ncurses in them.

6) Labeling the binaries. The opengrads builds have consistently used
the config.guess script to determine the the architecture labeling of
the tarballs, while COLA has been using Linux distro specific
labeling. My experience is that the i686-pc-linux binaries have been
extremely portable, with the x86_64 slightly less so. Even when the
x86_64 did not quite work, rebuilding against the pre-compiled x86_64
supplibs did the trick. And in most cases the i686 built works on
x86_64, so many users just went with that. It took some
experimentation, and excluding the openssl/termcap libraries is one of
the fine tunings I had to do.

  Just my 2 cents.

       Arlindo



On Fri, Aug 1, 2008 at 9:59 AM, Jennifer Adams <jm...@co...> 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
>



-- 
Arlindo da Silva
da...@al...

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

Re: [Opengrads-devel] dynamic supplibs checking

[Patrice D. <per...@fr...>]

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.

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

--
Pat

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

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

Re: [Opengrads-devel] dynamic supplibs checking

[Patrice D. <per...@fr...>]

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? 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. Also those
macros in fact come from other sources and should be kept synchronized
with these sources (mostly opendap).

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

> 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?

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


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.

--
Pat

[Opengrads-devel] dynamic supplibs checking

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

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. 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 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" .  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)

Doesn't that seem more reasonable?

Jennifer

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

Re: [Opengrads-devel] the build environment

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

On Jul 25, 2008, at 11:01 AM, Arlindo da Silva wrote:

> On Fri, Jul 25, 2008 at 9:16 AM, Jennifer Adams <jm...@co...>  
> wrote:
>> I have got it to work by creating a new macro in acinclude.m4:
>>
>
> This works and is more flexible than what I had done which was to have
> this macro in Makefile.am that assumed a prescribed supplib structure:
>
> INCLUDES  = -I$(supp_include_dir) \
>                           -I$(supp_include_dir)/curl \
>                           -I$(supp_include_dir)/xml2 \
>                           -I$(supp_include_dir)/gd \
>                           -I$(supp_include_dir)/gadap \
>                           -I$(supp_include_dir)/udunits \
>                           -I$(supp_include_dir)/hdf \
>                           -I$(supp_include_dir)/jpeg \
>                           -I$(supp_include_dir)/libpng \
>                           -I$(supp_include_dir)/zlib \
>                           -I$(supp_include_dir)/X11/neXtaw \
>                           -I$(supp_include_dir)/libsx \
>                           -I$(supp_include_dir)/grib2c \
>                           -I$(supp_include_dir)/jasper \
>                            $(X_CFLAGS) $(XAW_CFLAGS) $(GD_CFLAGS) \
>                            $(HDF4_CFLAGS)
>
> Where are you defining  the list of subdirectories to be searched?

At the moment, this list of include subdirectories is still in  
Makefile.am, and is fixed for compiling everything regardless if  
there's anything relevant in those subdirectories. (As I mentioned  
earlier, I change things slowly, so I can track the problems more  
readily.) For now, I'm using the GA_SET_INCLUDE_VAR macro just for  
isolating ./dap/netcdf.h and ./netcdf/netcdf.h.

By the way, I don't think the subdirs /curl and /xml2 are needed to  
build anything for GrADS, and I use /dap which contains the netcdf.h  
from libnc-dap and the *.h files from the gadap library.

> How would you handle the cases when netcdf is not coming from the
> supplibs?
For the moment, I am trying to get everything working to my  
understanding and satisfaction assuming everything is coming from the  
supplibs. I will add the dynamic library detection on top of that  
when I am ready.

> In our case, NC_CFLAGS/NCDAP_CFLAGS  are defined outside the
> Makefile. Pat has macros to either use the supplibs or else discover
> netcdf in the system and set NC_CFLAGS accordingly; so this logic is
> outside the Makefile.
I noticed that Pat's code adds a supplibs/bin directory that contains  
programs like dap-config and ncdap-config. That's a clever way to get  
around the problem of different dap_libs for different operating  
systems.

>
> Note: "Why then the INCLUDES macro above with the list of directories
> under the supplibs?",  you ask. In this case the suplibs would not be
> found (could set SUPPLIBS to /dev/null). Having INCLUDES in
> configure.ac, or even in the m4 macro GA_DEF_SUPPLIBS would be a
> better solution.
Yes, the more you can avoid hard-coded solutions, the better.

By the way, I have added library versions and URLs to the 'q config'  
output. Like this:

This version of GrADS has been configured with the following options:
   o Built on a LITTLE ENDIAN machine
   o Command line editing ENABLED
       readline-5.0  http://tiswww.case.edu/php/chet/readline/rltop.html
   o printim command for image output ENABLED
       zlib-1.2.3  http://www.zlib.net/
       libpng-1.2.18  http://www.libpng.org/pub/png/libpng.html
       gd-2.0.34  http://www.libgd.org/Main_Page
   o GRIB2 interface ENABLED
       g2clib-1.0.5  http://www.nco.ncep.noaa.gov/pmb/codes/GRIB2
       jasper-1.701.0  http://www.ece.uvic.ca/~mdadams/jasper
       jpeg-6b  27-Mar-1998  http://www.ijg.org
   o NetCDF interface ENABLED
       libnc-dap "3.7.0" of Feb 15 2007 09:14:25 $  http:// 
www.opendap.org
   o NCSA HDF interface ENABLED
       HDF4.2r3  http://hdf.ncsa.uiuc.edu
   o Athena Widget GUI DISABLED
   o OPeNDAP gridded data interface ENABLED
       libdap 3.7.8  http://www.opendap.org
   o OPeNDAP station data interface ENABLED
       libgadap 2.0  http://iges.org/grads/gadoc/supplibs.html


I am also getting ready to release libgadap-2.0, which will go with  
GrADS 2.0 and GDS 2.0 and will have the new copyright.

--Jennifer

Re: [Opengrads-devel] the build environment

[Arlindo da S. <da...@al...>]

On Fri, Jul 25, 2008 at 9:16 AM, Jennifer Adams <jm...@co...> wrote:
> I have got it to work by creating a new macro in acinclude.m4:
> dnl GA_SET_INCLUDE_VAR : Puts necessary options to compile with include
> directories given
> dnl                  into a shell variable.
> dnl   args:   : shell-variable-name, list-of-directories
> AC_DEFUN([GA_SET_INCLUDE_VAR],
> [
>   ga_include_prefix='-I$(supp_include_dir)/'
>   for ga_include_name in $2 ; do
>       $1="$$1 ${ga_include_prefix}${ga_include_name}"
>   done
> ])
>

This works and is more flexible than what I had done which was to have
this macro in Makefile.am that assumed a prescribed supplib structure:

INCLUDES  = -I$(supp_include_dir) \
                          -I$(supp_include_dir)/curl \
                          -I$(supp_include_dir)/xml2 \
                          -I$(supp_include_dir)/gd \
                          -I$(supp_include_dir)/gadap \
                          -I$(supp_include_dir)/udunits \
                          -I$(supp_include_dir)/hdf \
                          -I$(supp_include_dir)/jpeg \
                          -I$(supp_include_dir)/libpng \
                          -I$(supp_include_dir)/zlib \
                          -I$(supp_include_dir)/X11/neXtaw \
                          -I$(supp_include_dir)/libsx \
                          -I$(supp_include_dir)/grib2c \
                          -I$(supp_include_dir)/jasper \
                           $(X_CFLAGS) $(XAW_CFLAGS) $(GD_CFLAGS) \
                           $(HDF4_CFLAGS)

Where are you defining  the list of subdirectories to be searched?

> Now configure.ac has this:
> use_nc=no
> if test "$with_nc" != "no" ; then
>   echo "Checking netcdf support..."
>   GA_CHECK_NC([use_nc=yes], {})
> fi
> if test $use_nc = "yes" ; then
>   GA_SET_INCLUDE_VAR(nc_include, [netcdf])
>   AC_SUBST(nc_include)
>   if test $use_hdf = "yes" ; then
>     GA_SET_LIB_VAR(nc_libs, [netcdf])
>   else
>     GA_SET_LIB_VAR(nc_libs, [netcdf udunits])
>   fi
>   AC_SUBST(nc_libs)
>   AC_DEFINE(USESDF, 1, [Enable netcdf])
>   echo "+ netcdf enabled"
> else
>   AC_DEFINE(USESDF, 0, [Enable netcdf])
>   echo "- netcdf disabled"
> fi
> echo
> And my Makefile has this:
> nc_include =  -I$(supp_include_dir)/netcdf

How would you handle the cases when netcdf is not coming from the
supplibs? In our case, NC_CFLAGS/NCDAP_CFLAGS  are defined outside the
Makefile. Pat has macros to either use the supplibs or else discover
netcdf in the system and set NC_CFLAGS accordingly; so this logic is
outside the Makefile.

Note: "Why then the INCLUDES macro above with the list of directories
under the supplibs?",  you ask. In this case the suplibs would not be
found (could set SUPPLIBS to /dev/null). Having INCLUDES in
configure.ac, or even in the m4 macro GA_DEF_SUPPLIBS would be a
better solution.

      Arlindo.


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] the build environment

[Arlindo da S. <da...@al...>]

On Fri, Jul 25, 2008 at 7:33 AM, Jennifer Adams <jm...@co...> wrote:
>
> On Jul 25, 2008, at 12:25 AM, Arlindo da Silva wrote:
>
> On Thu, Jul 24, 2008 at 3:11 PM, Jennifer Adams <jm...@co...> wrote:
>
> Dear All,
> I am finally getting around to working on the build environment. I need
> help!!!
> I have changed the expected directory structure of $supplibs/include/ so now
> GrADS will look for subdirectories for each library. This led to me editing
> configure.in, acinclude.m4, and src/Makefile.am.  I am using the latest
> opengrads src (2.0.a2.oga.1) as a guide. My approach is to update things
> slowly, making sure they work before updating the next.
>
> This may work, but it could be very painful.
>
> Painstaking, but not painful. I'm glad to learn how to control the configure
> process, and it's much easier for me to support code I have thoroughly
> picked over.

I hear you; sometimes I do reverse picking over. I start with
something that works and then examine it line by line
revising/adapting it as I go long.  Absolutely, if you are going to
support it you need to be comfortable with it.

> I am working on an intel mac running 10.4.11. autoconf version
> 2.59. I will try using autoreconf instead of the bootstrap script and see if
> that helps.

I am currently running Mac OS X 10.5.4 and autoconf  2.62 I installed
from mac ports, but until very recently I was running on tiger
10.4.something; autoconf 2.59 shoul be recent enough.

   Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] the build environment

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

I have got it to work by creating a new macro in acinclude.m4:

dnl GA_SET_INCLUDE_VAR : Puts necessary options to compile with  
include directories given
dnl                  into a shell variable.
dnl   args:	   : shell-variable-name, list-of-directories
AC_DEFUN([GA_SET_INCLUDE_VAR],
[
   ga_include_prefix='-I$(supp_include_dir)/'

   for ga_include_name in $2 ; do
       $1="$$1 ${ga_include_prefix}${ga_include_name}"
   done
])


Now configure.ac has this:

use_nc=no
if test "$with_nc" != "no" ; then
   echo "Checking netcdf support..."
   GA_CHECK_NC([use_nc=yes], {})
fi
if test $use_nc = "yes" ; then
   GA_SET_INCLUDE_VAR(nc_include, [netcdf])
   AC_SUBST(nc_include)
   if test $use_hdf = "yes" ; then
     GA_SET_LIB_VAR(nc_libs, [netcdf])
   else
     GA_SET_LIB_VAR(nc_libs, [netcdf udunits])
   fi
   AC_SUBST(nc_libs)
   AC_DEFINE(USESDF, 1, [Enable netcdf])
   echo "+ netcdf enabled"
else
   AC_DEFINE(USESDF, 0, [Enable netcdf])
   echo "- netcdf disabled"
fi
echo

And my Makefile has this:
nc_include =  -I$(supp_include_dir)/netcdf

--Jennifer


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

Re: [Opengrads-devel] the build environment

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

On Jul 25, 2008, at 12:25 AM, Arlindo da Silva wrote:

> On Thu, Jul 24, 2008 at 3:11 PM, Jennifer Adams <jm...@co...>  
> wrote:
>> Dear All,
>> I am finally getting around to working on the build environment. I  
>> need
>> help!!!
>> I have changed the expected directory structure of $supplibs/ 
>> include/ so now
>> GrADS will look for subdirectories for each library. This led to  
>> me editing
>> configure.in, acinclude.m4, and src/Makefile.am.  I am using the  
>> latest
>> opengrads src (2.0.a2.oga.1) as a guide. My approach is to update  
>> things
>> slowly, making sure they work before updating the next.
>
> This may work, but it could be very painful.
Painstaking, but not painful. I'm glad to learn how to control the  
configure process, and it's much easier for me to support code I have  
thoroughly picked over. I am working on an intel mac running 10.4.11.  
autoconf version 2.59. I will try using autoreconf instead of the  
bootstrap script and see if that helps.
--Jennifer

> We also evolved slowly
> before we reached the current configuration, with a lot of fine tuning
> along the way. Trying to retrace the same steps may be very time
> consuming.  Another approach is for you to start with the autoconf
> structure from opengrads, and replace the *.c, *.h under src with your
> current sources and give it a go (If you give me your current sources
> I can make sure it builds with the opengrads autoconf structure
> without touching your sources).
>
>> So, the
>> dynamic-supplib-detection is not in yet. One thing that is not  
>> working is
>> adding the proper include directory for netcdf.h when compiling  
>> grads and
>> gradsdap. This is done with a variable called nc_include, which is  
>> set in
>> configure.in:
>> use_nc=no
>> if test "$with_nc" != "no" ; then
>>   echo "Checking netcdf support..."
>>   GA_CHECK_NC([use_nc=yes], {})
>> fi
>> if test $use_nc = "yes" ; then
>>   nc_include = "-I\$(supp_include_dir)/netcdf"
>>   AC_SUBST(nc_include)
>>   GA_SET_LIB_VAR(nc_libs, [netcdf udunits])
>>   AC_SUBST(nc_libs)
>>   AC_DEFINE(USESDF, 1, [Enable netcdf])
>>   echo "+ netcdf enabled"
>> else
>>   AC_DEFINE(USESDF, 0, [Enable netcdf])
>>   echo "- netcdf disabled"
>> fi
>> I put the nc_include variable in  src/Makefile.am like this:
>>   COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -DUSEGADODS=0
>> But after running ./bootstrap and ./configure, nc_include is empty  
>> in the
>> Makefile.
>
> The bootstrap script is deprecated; I usually use "autoreconf". Also,
> keeping up with current practice, configure.in has been renamed
> configure.ac ("in" kind of files is usually produced after running
> autoconf, like Makefile.in). Which version of autoconf are you using?
>
>> Here I grep for it in the top level, and the directories below:
>>> grep nc_include *
>> Makefile:nc_include =
>> Makefile.in:nc_include = @nc_include@
>> config.log:nc_include=''
>> config.status:s,@nc_include@,,;t t
>> configure:ac_subst_vars='SHELL <....snipped...> nc_include  
>> <...snipped...>
>> configure:  nc_include = "-I\$(supp_include_dir)/netcdf"
>> configure:s,@nc_include@,$nc_include,;t t
>> configure.in:  nc_include = "-I\$(supp_include_dir)/netcdf"
>> configure.in:  AC_SUBST(nc_include)
>>> grep nc_include */*
>> autom4te.cache/output.0:ac_subst_vars='SHELL <....snipped...>  
>> nc_include
>> <...snipped...>
>> autom4te.cache/output.0:  nc_include = "-I\$(supp_include_dir)/ 
>> netcdf"
>> autom4te.cache/output.0:s,@nc_include@,$nc_include,;t t
>> autom4te.cache/traces.0:m4trace:configure.in:358: -1- AC_SUBST 
>> ([nc_include])
>> src/Makefile:nc_include =
>> src/Makefile:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 - 
>> DUSEGADODS=0
>> src/Makefile.am:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0
>> -DUSEGADODS=0
>> src/Makefile.in:nc_include = @nc_include@
>> src/Makefile.in:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0
>> -DUSEGADODS=0
>>
>> What am I doing wrong?
>
> I remember having similar issues, but frankly I cannot remember
> exactly what I did.  I'd have to get your tarball and poke around. In
> the new structure we now define NC_CFLAGS which among other things,
> define the include dirs; parts of NC_CFLAGS is defined inside the
> netcdf/hdf specific m4 macros.  Pat has a good eye for these things,
> perhaps he can spot something from your output.
>
> Can you make sense of our configure.ac/Makefile.am? I could give you a
> walk thru if you would like. There is no rocket science in this ---
> simply little gotchas here and there that after lots of
> experimentation and testing one gets it working. Are you sure you want
> to go thru the same teething pain?  Either way, I'd be glad to help,
> but I'd need to have your sandbox to see what is going on.
>
>     Arlindo
>
> -- 
> Arlindo da Silva
> da...@al...
>
> ---------------------------------------------------------------------- 
> ---
> 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...

Re: [Opengrads-devel] the build environment

[Patrice D. <per...@fr...>]

On Thu, Jul 24, 2008 at 03:11:38PM -0400, Jennifer Adams wrote:
> Dear All,
> I am finally getting around to working on the build environment. I need 
> help!!!
>
>
> But after running ./bootstrap and ./configure, nc_include is empty in  
> the Makefile.

it looks right. You should adapt to autoreconf before doing the
remaining, though. I think I can't help further without access to the
actual code.

--
Pat

Re: [Opengrads-devel] the build environment

[Arlindo da S. <da...@al...>]

On Thu, Jul 24, 2008 at 3:11 PM, Jennifer Adams <jm...@co...> wrote:
> Dear All,
> I am finally getting around to working on the build environment. I need
> help!!!
> I have changed the expected directory structure of $supplibs/include/ so now
> GrADS will look for subdirectories for each library. This led to me editing
> configure.in, acinclude.m4, and src/Makefile.am.  I am using the latest
> opengrads src (2.0.a2.oga.1) as a guide. My approach is to update things
> slowly, making sure they work before updating the next.

This may work, but it could be very painful. We also evolved slowly
before we reached the current configuration, with a lot of fine tuning
along the way. Trying to retrace the same steps may be very time
consuming.  Another approach is for you to start with the autoconf
structure from opengrads, and replace the *.c, *.h under src with your
current sources and give it a go (If you give me your current sources
I can make sure it builds with the opengrads autoconf structure
without touching your sources).

> So, the
> dynamic-supplib-detection is not in yet. One thing that is not working is
> adding the proper include directory for netcdf.h when compiling grads and
> gradsdap. This is done with a variable called nc_include, which is set in
> configure.in:
> use_nc=no
> if test "$with_nc" != "no" ; then
>   echo "Checking netcdf support..."
>   GA_CHECK_NC([use_nc=yes], {})
> fi
> if test $use_nc = "yes" ; then
>   nc_include = "-I\$(supp_include_dir)/netcdf"
>   AC_SUBST(nc_include)
>   GA_SET_LIB_VAR(nc_libs, [netcdf udunits])
>   AC_SUBST(nc_libs)
>   AC_DEFINE(USESDF, 1, [Enable netcdf])
>   echo "+ netcdf enabled"
> else
>   AC_DEFINE(USESDF, 0, [Enable netcdf])
>   echo "- netcdf disabled"
> fi
> I put the nc_include variable in  src/Makefile.am like this:
>   COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -DUSEGADODS=0
> But after running ./bootstrap and ./configure, nc_include is empty in the
> Makefile.

The bootstrap script is deprecated; I usually use "autoreconf". Also,
keeping up with current practice, configure.in has been renamed
configure.ac ("in" kind of files is usually produced after running
autoconf, like Makefile.in). Which version of autoconf are you using?

> Here I grep for it in the top level, and the directories below:
>> grep nc_include *
> Makefile:nc_include =
> Makefile.in:nc_include = @nc_include@
> config.log:nc_include=''
> config.status:s,@nc_include@,,;t t
> configure:ac_subst_vars='SHELL <....snipped...> nc_include <...snipped...>
> configure:  nc_include = "-I\$(supp_include_dir)/netcdf"
> configure:s,@nc_include@,$nc_include,;t t
> configure.in:  nc_include = "-I\$(supp_include_dir)/netcdf"
> configure.in:  AC_SUBST(nc_include)
>> grep nc_include */*
> autom4te.cache/output.0:ac_subst_vars='SHELL <....snipped...> nc_include
> <...snipped...>
> autom4te.cache/output.0:  nc_include = "-I\$(supp_include_dir)/netcdf"
> autom4te.cache/output.0:s,@nc_include@,$nc_include,;t t
> autom4te.cache/traces.0:m4trace:configure.in:358: -1- AC_SUBST([nc_include])
> src/Makefile:nc_include =
> src/Makefile:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -DUSEGADODS=0
> src/Makefile.am:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0
> -DUSEGADODS=0
> src/Makefile.in:nc_include = @nc_include@
> src/Makefile.in:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0
> -DUSEGADODS=0
>
> What am I doing wrong?

I remember having similar issues, but frankly I cannot remember
exactly what I did.  I'd have to get your tarball and poke around. In
the new structure we now define NC_CFLAGS which among other things,
define the include dirs; parts of NC_CFLAGS is defined inside the
netcdf/hdf specific m4 macros.  Pat has a good eye for these things,
perhaps he can spot something from your output.

Can you make sense of our configure.ac/Makefile.am? I could give you a
walk thru if you would like. There is no rocket science in this ---
simply little gotchas here and there that after lots of
experimentation and testing one gets it working. Are you sure you want
to go thru the same teething pain?  Either way, I'd be glad to help,
but I'd need to have your sandbox to see what is going on.

    Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] the build environment [addendum]

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

The $nc_include variable is almost exactly like $NC_CFLAGS in the  
opengrads build. I renamed it to distinguish it because I added one  
more step (the AC_SUBST(nc_include) call). I was trying to reproduce  
the behavior of  $dap_libs, which is working in my build. Am I  
forgetting to add something somewhere?
--Jennifer

On Jul 24, 2008, at 3:11 PM, Jennifer Adams wrote:

> Dear All,
> I am finally getting around to working on the build environment. I  
> need help!!!
>
> I have changed the expected directory structure of $supplibs/ 
> include/ so now GrADS will look for subdirectories for each  
> library. This led to me editing configure.in, acinclude.m4, and src/ 
> Makefile.am. I am using the latest opengrads src (2.0.a2.oga.1) as  
> a guide. My approach is to update things slowly, making sure they  
> work before updating the next. So, the dynamic-supplib-detection is  
> not in yet. One thing that is not working is adding the proper  
> include directory for netcdf.h when compiling grads and gradsdap.  
> This is done with a variable called nc_include, which is set in  
> configure.in:
>
> use_nc=no
> if test "$with_nc" != "no" ; then
>   echo "Checking netcdf support..."
>   GA_CHECK_NC([use_nc=yes], {})
> fi
> if test $use_nc = "yes" ; then
>   nc_include = "-I\$(supp_include_dir)/netcdf"
>   AC_SUBST(nc_include)
>   GA_SET_LIB_VAR(nc_libs, [netcdf udunits])
>   AC_SUBST(nc_libs)
>   AC_DEFINE(USESDF, 1, [Enable netcdf])
>   echo "+ netcdf enabled"
> else
>   AC_DEFINE(USESDF, 0, [Enable netcdf])
>   echo "- netcdf disabled"
> fi
>
> I put the nc_include variable in  src/Makefile.am like this:
>   COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -DUSEGADODS=0
>
> But after running ./bootstrap and ./configure, nc_include is empty  
> in the Makefile.
> Here I grep for it in the top level, and the directories below:
>
> > grep nc_include *
> Makefile:nc_include =
> Makefile.in:nc_include = @nc_include@
> config.log:nc_include=''
> config.status:s,@nc_include@,,;t t
> configure:ac_subst_vars='SHELL <....snipped...> nc_include  
> <...snipped...>
> configure:  nc_include = "-I\$(supp_include_dir)/netcdf"
> configure:s,@nc_include@,$nc_include,;t t
> configure.in:  nc_include = "-I\$(supp_include_dir)/netcdf"
> configure.in:  AC_SUBST(nc_include)
>
> > grep nc_include */*
> autom4te.cache/output.0:ac_subst_vars='SHELL <....snipped...>  
> nc_include <...snipped...>
> autom4te.cache/output.0:  nc_include = "-I\$(supp_include_dir)/netcdf"
> autom4te.cache/output.0:s,@nc_include@,$nc_include,;t t
> autom4te.cache/traces.0:m4trace:configure.in:358: -1- AC_SUBST 
> ([nc_include])
> src/Makefile:nc_include =
> src/Makefile:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 - 
> DUSEGADODS=0
> src/Makefile.am:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 - 
> DUSEGADODS=0
> src/Makefile.in:nc_include = @nc_include@
> src/Makefile.in:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 - 
> DUSEGADODS=0
>
>
> What am I doing wrong?
>
> Jennifer
>
> --
> Jennifer M. Adams
> IGES/COLA
> 4041 Powder Mill Road, Suite 302
> Calverton, MD 20705
> jm...@co...
>
>
>
> ---------------------------------------------------------------------- 
> ---
> 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...

Re: [Opengrads-devel] the build environment

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

Dear All,
I am finally getting around to working on the build environment. I  
need help!!!

I have changed the expected directory structure of $supplibs/include/  
so now GrADS will look for subdirectories for each library. This led  
to me editing configure.in, acinclude.m4, and src/Makefile.am. I am  
using the latest opengrads src (2.0.a2.oga.1) as a guide. My approach  
is to update things slowly, making sure they work before updating the  
next. So, the dynamic-supplib-detection is not in yet. One thing that  
is not working is adding the proper include directory for netcdf.h  
when compiling grads and gradsdap. This is done with a variable  
called nc_include, which is set in configure.in:

use_nc=no
if test "$with_nc" != "no" ; then
   echo "Checking netcdf support..."
   GA_CHECK_NC([use_nc=yes], {})
fi
if test $use_nc = "yes" ; then
   nc_include = "-I\$(supp_include_dir)/netcdf"
   AC_SUBST(nc_include)
   GA_SET_LIB_VAR(nc_libs, [netcdf udunits])
   AC_SUBST(nc_libs)
   AC_DEFINE(USESDF, 1, [Enable netcdf])
   echo "+ netcdf enabled"
else
   AC_DEFINE(USESDF, 0, [Enable netcdf])
   echo "- netcdf disabled"
fi

I put the nc_include variable in  src/Makefile.am like this:
   COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -DUSEGADODS=0

But after running ./bootstrap and ./configure, nc_include is empty in  
the Makefile.
Here I grep for it in the top level, and the directories below:

 > grep nc_include *
Makefile:nc_include =
Makefile.in:nc_include = @nc_include@
config.log:nc_include=''
config.status:s,@nc_include@,,;t t
configure:ac_subst_vars='SHELL <....snipped...> nc_include  
<...snipped...>
configure:  nc_include = "-I\$(supp_include_dir)/netcdf"
configure:s,@nc_include@,$nc_include,;t t
configure.in:  nc_include = "-I\$(supp_include_dir)/netcdf"
configure.in:  AC_SUBST(nc_include)

 > grep nc_include */*
autom4te.cache/output.0:ac_subst_vars='SHELL <....snipped...>  
nc_include <...snipped...>
autom4te.cache/output.0:  nc_include = "-I\$(supp_include_dir)/netcdf"
autom4te.cache/output.0:s,@nc_include@,$nc_include,;t t
autom4te.cache/traces.0:m4trace:configure.in:358: -1- AC_SUBST 
([nc_include])
src/Makefile:nc_include =
src/Makefile:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 - 
DUSEGADODS=0
src/Makefile.am:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 - 
DUSEGADODS=0
src/Makefile.in:nc_include = @nc_include@
src/Makefile.in:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 - 
DUSEGADODS=0


What am I doing wrong?

Jennifer

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

Re: [Opengrads-devel] GrADS and TTF

[Brian D. <do...@co...>]

I am looking at incorporating the Cairo package which includes font  
support (not truetype but freetype?) ... Brian

On Jul 13, 2008, at 8:45 PM, Arlindo da Silva wrote:

> On Sun, Jul 13, 2008 at 7:58 PM, Luiz Rodrigo Tozzi
> <lui...@gm...> wrote:
>> Hi all,
>>
>> I'm still working on the GrADS PHP documentation but a friend of  
>> mine asked
>> me something and I think you are the best people to answer it.
>>
>> Is there any plans for GrADS and/or OpenGrADS to work with  
>> TrueType Fonts?
>>
>> Everybody knows GrADS has a "non trivial way" to deal with fonts  
>> and I was
>> wondering how hard it would be to implement it.
>>
>> Maybe the right (and easier) way would be creating a TTF2GrADS  
>> executable to
>> convert TTF to GrADS font file.
>>
>> What do you think? Is there any plans for it?
>>
>
> As you know GrADS renders its own font using very basic vector
> graphics instructions (pen up/pen down a la turtle graphics).  My
> recollection is that in the past (read: late 80's/early 90's) it was a
> real pain to rely on "hardware fonts" and having GrADS do all the font
> drawing was the only way to guarantee platform independency.  The
> proper rendering of fonts with anti-aliasing and what not is tricky
> business, it is not a simple matter of translating TTFs into GrADS
> font format. One is better off relying on some of the excellent
> libraries available for drawing fonts.
>
> Matt Munnich contributed some FreeType support for v1.9 but to the
> best of my knowledge I it was never incorporated in the main GrADS
> codebase.  I believe Brian is doing some overhaul of the graphics
> rendering in v2 which may include some support for TTF; I'm cc'ing him
> as he may be able to give us an update.
>
>     Arilindo
>
> -- 
> Arlindo da Silva
> da...@al...

Re: [Opengrads-devel] GrADS and TTF

[Arlindo da S. <da...@al...>]

On Sun, Jul 13, 2008 at 7:58 PM, Luiz Rodrigo Tozzi
<lui...@gm...> wrote:
> Hi all,
>
> I'm still working on the GrADS PHP documentation but a friend of mine asked
> me something and I think you are the best people to answer it.
>
> Is there any plans for GrADS and/or OpenGrADS to work with TrueType Fonts?
>
> Everybody knows GrADS has a "non trivial way" to deal with fonts and I was
> wondering how hard it would be to implement it.
>
> Maybe the right (and easier) way would be creating a TTF2GrADS executable to
> convert TTF to GrADS font file.
>
> What do you think? Is there any plans for it?
>

As you know GrADS renders its own font using very basic vector
graphics instructions (pen up/pen down a la turtle graphics).  My
recollection is that in the past (read: late 80's/early 90's) it was a
real pain to rely on "hardware fonts" and having GrADS do all the font
drawing was the only way to guarantee platform independency.  The
proper rendering of fonts with anti-aliasing and what not is tricky
business, it is not a simple matter of translating TTFs into GrADS
font format. One is better off relying on some of the excellent
libraries available for drawing fonts.

Matt Munnich contributed some FreeType support for v1.9 but to the
best of my knowledge I it was never incorporated in the main GrADS
codebase.  I believe Brian is doing some overhaul of the graphics
rendering in v2 which may include some support for TTF; I'm cc'ing him
as he may be able to give us an update.

    Arilindo

-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] GrADS and TTF

[Luiz R. T. <lui...@gm...>]

Hi all,

I'm still working on the GrADS PHP documentation but a friend of mine asked
me something and I think you are the best people to answer it.

Is there any plans for GrADS and/or OpenGrADS to work with TrueType Fonts?

Everybody knows GrADS has a "non trivial way" to deal with fonts and I was
wondering how hard it would be to implement it.

Maybe the right (and easier) way would be creating a TTF2GrADS executable to
convert TTF to GrADS font file.

What do you think? Is there any plans for it?

--

Luiz Rodrigo Lins Tozzi
lui...@gm...
http://thedealwith.blogspot.com/

Re: [Opengrads-devel] Testers for the windows version of grads-2.0.a2 supporting GRIB2

[Arlindo da S. <da...@al...>]

On Wed, Jul 9, 2008 at 3:17 PM, John Huddleston <jhu...@hu...> wrote:
>
> Hi
>
> I've built a version of grads-2.0.a2 for windows.

I am very glad to hear that you have done a Win32 build. I've been
doing win32 for GrADS for many years. The ironic thing is that I very
seldom use windows, and have very limited access to Windows these
days.

>
> Initially it will require a Cygwin implementation on your PC.
>
>

Here is a suggestion for making your binaries more readily usable by
the average user who does not have cygwin installed but has Win32
grads 1.9.0-rc1. (Win32 GrADS bundles the essential cygwin dll's, so
it should have all that is needed to build your binaries). Install the
Win32 Superpack for v1.9.:

    http://sourceforge.net/project/showfiles.php?group_id=161773&package_id=270750

Rename your "grads.exe" to something like "grads2.exe". Copy both
"grads2.exe" and "gradsdap.exe" to the C:/GRADS19/win32 directory. For
now, you will need to set GADDIR to C:/GRADS19/dat, and perhaps GASCRP
to C:/GRADS19/lib.  I can tell you later how to create a grads2.dll
and gradsdap.dll so that all these details are automatically taken
care of.

There is a good chance that both "grads2.exe" and "gradsdap.exe" would
work even when cygwin is not installed. I can try it for you if you
send me your binaries.


>
> There is not much documentation for the new features; however, I've tested it against the older ones.
>

I have developed a test suite for GrADS 2 that you could use to test
your binaries (I used an equivalent test suite for testing v1.9 with
cygwin).  All you need is to have cygwin's python installed (it is
pretty standard, you may already have it). Download the OpenGrADS
patched sources for v2.0.a2:

      http://opengrads.org/devel/grads2/grads-2.0.a2.oga.1.tar.gz

Untar it, and place the pytests/ subdiretory parallel to your src/
directory (with your current codebase). Then enter

cd pytests
python grads_tests.py

This will run a battery of tests, and give you a report at the end.
This is meant to test grads itself, not the python interface. I just
wrote the test suite in python for convenience. It also bundles all
the necessary data files.

> If anyone is interested in testing this version of GrADS on Windows I can send you a copy of the EXE.

Send me your binaries and I can test whether it runs inside the Win32
GrADS v1.9.0 distribution without having cygwin installed; I have such
configuration on my tests machine, also known as my wife's computer.

BTW, I am planning to have an OpenGrADS release of GrADS v2 sometime
this summer, including a Win32 build (very much along the same lines
of v1.9.0-rc1). This release will include hooks to enable a fully
functional PyGrADS with GrADS v2, along with Java and Matlab
interfaces. If you like to join force with us at OpenGrADS, I've been
looking for someone that could look after the Win32 builds. Are you
interested?

  Cheers!

      Arlindo

--
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] OpenGrADS development - PHP interface

[Arlindo da S. <da...@al...>]

Luiz,

  I have added you to the OpenGrADS project on sf.net and also on the
OpenGrADS wiki (we do not use the sf.net wiki because it is not MediaWiki,
so the wiki account is separate from sf.net). A couple of notes:

1) I have checked in your tarball and created a CVS module that includes our
generic test data directory. For checking it out:

export CVS_RSH=ssh
cvs -z3 -d:ext:lui...@op...:/cvsroot/opengrads co
-P gradsPHP*

*Unless you have setup your SSH keys this will ask for your sf.net password.
For SSH key info check this:

        http://alexandria.wiki.sourceforge.net/SSH+Key+Generation

I strongly recommend you setup your ssh keys for passwordless access to cvs.

2) I have not checked in your shapefiles because I was not sure whether they
were freely available; sf.net does not allow check in of proprietary
data/software. It must be covered by some form of opensource license. BTW,
the model.nc file is under data, you may need to adjust your test script.

3) I have created stubs for the standard files COPYING, README, INSTALL,
etc. Please populate these files when you have a chance. Take a look at one
of the other packages for examples, e.g.,

  cvs .... co -P pygrads
  cvs ... co -P gerl

4) You should have received an e-mail with your wiki password. I have
created a place holder wiki page for the PHP interface:

      http://opengrads.org/wiki/index.php?title=PHP_Interface_to_GrADS

Edit it as you see fit. This is just a copy of the Perl wiki now.

5) You need to add licensing terms to each source file, and also in the
COPYING file.  Most of my stuff is under GPL, some under a Perl style
license term. See the gerl/pygrads packages for examples. Sourceforge
requires an opensource license.

I was able to sucessfully run your test scripts on my Mac running Leopard.
It ran out of the box!

  Let me know if you have questions,

      Arlindo



On Wed, Jul 2, 2008 at 12:11 AM, Luiz Rodrigo Tozzi <
lui...@gm...> wrote:

> Hi Arlindo
>
> I'm sending to you the first prototype of the PHP interface, for you to
> test and see what I did until now.
>
> I spent some time trying to figure out how PHP deals with the data stream
> between grads and the PHP pipe system. I think I'll have to test it more
> along with the getError() function. For really basic stuff, its functional.
>
> Just like you suggested in the previous email, I rewrote the functions to
> be OO based and I organized it better. Now all of the functions obey the
> Echo and Verb-like output flags and most of the functions are able to handle
> this output in a raw way or in an array way.
>
> In the this tarball there are two simple examples of how it works.
> grads_shaded.php is a step by step script that only opens a nc file, sets
> the environment and plots an image. grads_points.php is a php script that
> coordinates a series of calls to retrieve variable values from some points
> using arrays, loops and other php stuff. this grads_points.php could receive
> the points coordinates and names from a MySQL database, get some information
> through GrADS and show it in a HTML-like PHP in the server. I already did
> that but creating the gs file and submiting into GrADS. Now it can be done
> within the PHP script!
>
>
> I'm interested in handling the graphical output of GrADS through GD
>>> but I don't know how to do it. I used to deal with GD programming in
>>> PHP but i don't know how it works in GrADS.
>>>
>>
>>
>> I am not clear exactly what kind of things would you like to do. You can
>> always write PNG from GrADS and read it from disk. You could also capture
>> the GrADS metafile through the pipe (I'd need to add an simple grads
>> extension for that) and then use GD interface to PHP to create the image in
>> PHP. (I'd recommend Cairo over GD as it is more capable.)
>>
>
> I noticed that using libipc I can get some slice of data and that's what
> I'm about to try now, but I was asking about capturing the GrADS metafile.
> In PHP, as in your Python interface, there are powerful tools to handle
> graphics, using GD or Cairo. One of those applications is the web based
> capability of displaying something you dynamically created. In my
> applications I can place a PNG over a satellite image using alpha channels
> and transparency, add text with TTF font, with "Portuguese characters" and
> use the image area completely, with no blanks in the sides.
>
> The point is: is it possible to add this grads extension, to handle GrADS
> metafile?
>
>
>> One question: does PHP have any way of efficiently representing numerical
>> arrays?
>>
>>
> If you are asking about n dimensional arrays, lists, vectors and things
> like these the answer is yes. Its not hard to work with it but I really dont
> know if there is a limit to the size of objects or something like it. But
> its easy to implement.
>
> I just subscribed to opengrads-devel list and I saw that you are working on
> a Matlab interface. Do you know if someone has ever tried to do a "R" (<
> http://www.r-project.org/>) interface? I used to work on it and its a very
> useful environment.
>
> By the way, there is something off-topic that I'm curious about: your name
> looks like a Portuguese-like name. Are you from Brazil or Portugal? Have you
> ever been here in Brazil? There are lots of people from here in the GrADS
> user list, specially in CPTEC, where I used to work. You may know José
> Pesquero, he is a heavy user from the GrADS list and a friend of mine.
>
> Peace!
>
> --
>
> Luiz Rodrigo Lins Tozzi
> lui...@gm...
> http://thedealwith.blogspot.com/
>
> On Wed, Jun 25, 2008 at 9:20 AM, Arlindo da Silva <da...@al...>
> wrote:
>
>> On Tue, Jun 24, 2008 at 11:46 PM, Luiz Rodrigo Tozzi <
>> lui...@gm...> wrote:
>>
>>> Hi Arlindo
>>>
>>> After reading the Gerl code and using it, I managed to translate the
>>> idea from Perl to PHP.
>>
>>
>> This is very nice! You got something already very functional.
>>
>>
>>> PHP is a bit different from Perl because there
>>> is no prompt to deal with PHP commands, only the interpreter of the
>>> command line or the web based interpreter.
>>>
>>
>> Even in perl, most times I just write a script.
>>
>>
>>>
>>> I began to write the PHP interface and now I can open the grads with
>>> the -u option, with bidirectional pipe. Some of the most common used
>>> commands are implemented. For an example:
>>>
>>
>> [...]
>>
>>
>>> I'm preparing the code to the Echo/Verb style you did in the Gerl and
>>> I can send you this first version of the code for you to have a look.
>>>
>>
>> These get really important for debugging. In batch sometimes one wants to
>> suppress most output except when something goes wrong.
>>
>>
>>>
>>> Is there something I forgot for this first pre-alpha prototype? I'm
>>> open for sugestions!
>>>
>>
>>  I see that you started with a non-OO prototype. The main advantage of an
>> OO interface is that you can instantiate more than one version of GrAS at a
>> time. For example when dealing with HDF and OPeNDAP files in v1.9 one end up
>> having to start 2 instances (one with gradshdf, another with gradsdods).
>> Another advantage of an OO approach is that it makes it easy to extended it
>> n different directions, while retaining the core functionality in a base
>> class.
>>
>>
>>>
>>> I'm interested in handling the graphical output of GrADS through GD
>>> but I don't know how to do it. I used to deal with GD programming in
>>> PHP but i don't know how it works in GrADS.
>>>
>>
>>
>> I am not clear exactly what kind of things would you like to do. You can
>> always write PNG from GrADS and read it from disk. You could also capture
>> the GrADS metafile through the pipe (I'd need to add an simple grads
>> extension for that) and then use GD interface to PHP to create the image in
>> PHP. (I'd recommend cairo over GD as it is more capable.)
>>
>> One question: does PHP have any way of efficiently representing numerical
>> arrays?
>>
>>    Again, congratulations! This is very exciting work. I look forward to
>> distribut it through opengrads as another interface to GrADS. Perhaps we
>> could start checking in to the repository what you already have.
>>
>>   Cheers!
>>
>>       Arlindo
>>
>>
>> ---- original message ----
>>
>> Hi Arlindo
>>
>> After reading the Gerl code and using it, I managed to translate the
>> idea from Perl to PHP. PHP is a bit different from Perl because there
>> is no prompt to deal with PHP commands, only the interpreter of the
>> command line or the web based interpreter.
>>
>> I began to write the PHP interface and now I can open the grads with
>> the -u option, with bidirectional pipe. Some of the most common used
>> commands are implemented. For an example:
>>
>> #!/usr/bin/php
>> <?php
>> include ("gradsPHP.php");
>>
>> // OPEN GRADS WITH OR WITHOUT OPTIONS
>> grads(array(
>>  "Bin" => "gradsnc",
>>  "Echo" => "0",
>>  "Opt" => "-b"
>>  ));
>> // or just grads();
>>
>> // OPEN THE FILE
>> ga_open("model.nc","nc");
>>
>> // SET LAT, LON, ETC
>> ga_set("lat","-23.8 -12.6");
>> ga_set("lon","-52.2 -39.4");
>> ga_set("gxout","shaded");
>> ga_set("grads","off");
>>
>> // DISPLAY PS
>> ga_display("ps");
>>
>> // DRAW THE TITLE CONTROLLING THE POSITION OF THE TITLE
>> ga_title("Pressao - Minas
>> Gerais",$opt=array("Font"=>"0","Size"=>".25","YOffset"=>".2"));
>>
>> // CBARN AND SHAPE CONTOURS
>> ga_cmd("run cbarn.gs");
>> ga_set("line","0");
>> ga_cmd("shp_lines est");
>> ga_cmd("shp_lines mun");
>> //ga_query("pos");
>>
>> // EXPORT THE IMAGE
>> ga_gxyat("ok.png");
>>
>> // CLOSE PIPES, PID...
>> ga_submit();
>>
>> // SHOW THE IMAGE
>> `animate ok.png`;
>>
>> ?>
>>
>> This is a "tutorial like program", where I used the gradsPHP.php
>> functions that arrange the commands and send them to grads through the
>> pipe.
>>
>> I create the ga_title() function based in Jennifer's title.gs script,
>> but in this case you can pass some attributes through an array of
>> options, including the Y position of the title. I obtain this
>> information using the "q gxinfo" and retriving the output using the
>> pipe system.
>>
>> The ga_cmd() function is the most generic function of the class. It
>> can send the commands like:
>>
>> ga_cmd("set x 1");
>> ga_cmd("set y 1");
>> ga_cmd("d ps");
>> ga_cmd("draw title something");
>>
>> or
>>
>> ga_cmd("
>> set x 1
>> set y 1
>> d ps
>> draw title something
>> ");
>>
>> or even
>>
>> ga_cmd($scriptgs);
>>
>> [$scriptgs is the content of a gs file]
>>
>>
>> I'm preparing the code to the Echo/Verb style you did in the Gerl and
>> I can send you this first version of the code for you to have a look.
>>
>> Is there something I forgot for this first pre-alpha prototype? I'm
>> open for sugestions!
>>
>> I'm interested in handling the graphical output of GrADS through GD
>> but I don't know how to do it. I used to deal with GD programming in
>> PHP but i don't know how it works in GrADS.
>>
>>
>> Peace!
>>
>> --
>>
>> Luiz Rodrigo Lins Tozzi
>> lui...@gm...
>>
>> --
>> Arlindo da Silva
>> da...@al...
>
>
>


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] OpenGrADS development - PHP interface

[Luiz R. T. <lui...@gm...>]

Ok, Arlindo

I'll work on it using "display => gxyat => svg file => php" and once its
stable I'll try using "display => php pipe"

I'll keep on writing the php code and, as soon as I have the permission,
I'll place it in the CVS.

Peace

--

Luiz Rodrigo Lins Tozzi
lui...@gm...
http://thedealwith.blogspot.com/

On Wed, Jul 2, 2008 at 4:21 PM, Arlindo da Silva <da...@al...>
wrote:

> On Wed, Jul 2, 2008 at 10:30 AM, Luiz Rodrigo Tozzi <
> lui...@gm...> wrote:
>
>>
>> Great. That will be my next step as soon as the IPC extension were able to
>> deal with metafile instructions. I have tons of php scripts that extract
>> information from a MySQL db and use GD to plot meteograms and graphs using
>> JpGraph (http://www.aditus.nu/jpgraph/). unfortunately this program is
>> not entirely free :(
>> the development to Cairo is only beginning in PHP but start from here is
>> something really interesting.
>>
>
> The gxyat extension can write SVG right now:
>
> ga-> d ts
> ga-> gxyat ts.svg
>
> SVG is an XML ASCII format for vector graphics; there is some PHP support
> for it.  Capturing the SVG through the pipe can be done with minimal work.
> SVG is complex but the kinds of files written by gxyat are simple. Capturing
> the GrADS metafile binary format is also an option. You can prototype this
> by writing it to disk with print. Getting it through the pipe would be an
> optimization step for increasing performance, nothing more.
>
>     Arlindo
>
>
>
> --
> Arlindo da Silva
> da...@al...
>

Re: [Opengrads-devel] OpenGrADS development - PHP interface

[Arlindo da S. <da...@al...>]

On Wed, Jul 2, 2008 at 10:30 AM, Luiz Rodrigo Tozzi <
lui...@gm...> wrote:

>
> Great. That will be my next step as soon as the IPC extension were able to
> deal with metafile instructions. I have tons of php scripts that extract
> information from a MySQL db and use GD to plot meteograms and graphs using
> JpGraph (http://www.aditus.nu/jpgraph/). unfortunately this program is not
> entirely free :(
> the development to Cairo is only beginning in PHP but start from here is
> something really interesting.
>

The gxyat extension can write SVG right now:

ga-> d ts
ga-> gxyat ts.svg

SVG is an XML ASCII format for vector graphics; there is some PHP support
for it.  Capturing the SVG through the pipe can be done with minimal work.
SVG is complex but the kinds of files written by gxyat are simple. Capturing
the GrADS metafile binary format is also an option. You can prototype this
by writing it to disk with print. Getting it through the pipe would be an
optimization step for increasing performance, nothing more.

    Arlindo



-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] OpenGrADS development - PHP interface

[Arlindo da S. <da...@al...>]

Rodrigo,

  A quick answer before bedtime.

On Wed, Jul 2, 2008 at 12:11 AM, Luiz Rodrigo Tozzi <
lui...@gm...> wrote:

> Hi Arlindo
>
> I'm sending to you the first prototype of the PHP interface, for you to
> test and see what I did until now.
>
> I spent some time trying to figure out how PHP deals with the data stream
> between grads and the PHP pipe system. I think I'll have to test it more
> along with the getError() function. For really basic stuff, its functional.
>

That sounds great. I'll take a look at it and check it in to the repository.
It would be good if you could use the repo for maintaining the PHP
interface. Are you familiar with CVS? Also, I'd need your sourceforge userid
to give you commit privileges to the repository and to the wiki.


>
> Just like you suggested in the previous email, I rewrote the functions to
> be OO based and I organized it better. Now all of the functions obey the
> Echo and Verb-like output flags and most of the functions are able to handle
> this output in a raw way or in an array way.
>

Nice.


>
> In the this tarball there are two simple examples of how it works.
> grads_shaded.php is a step by step script that only opens a nc file, sets
> the environment and plots an image. grads_points.php is a php script that
> coordinates a series of calls to retrieve variable values from some points
> using arrays, loops and other php stuff. this grads_points.php could receive
> the points coordinates and names from a MySQL database, get some information
> through GrADS and show it in a HTML-like PHP in the server. I already did
> that but creating the gs file and submiting into GrADS. Now it can be done
> within the PHP script!
>

One of the advantage of this approach is that you can parse the output of
each grads command and handle it appropriately if an error occurs.


>
>
> I'm interested in handling the graphical output of GrADS through GD
>>> but I don't know how to do it. I used to deal with GD programming in
>>> PHP but i don't know how it works in GrADS.
>>>
>>
>>
>> I am not clear exactly what kind of things would you like to do. You can
>> always write PNG from GrADS and read it from disk. You could also capture
>> the GrADS metafile through the pipe (I'd need to add an simple grads
>> extension for that) and then use GD interface to PHP to create the image in
>> PHP. (I'd recommend Cairo over GD as it is more capable.)
>>
>
> I noticed that using libipc I can get some slice of data and that's what
> I'm about to try now, but I was asking about capturing the GrADS metafile.
> In PHP, as in your Python interface, there are powerful tools to handle
> graphics, using GD or Cairo. One of those applications is the web based
> capability of displaying something you dynamically created. In my
> applications I can place a PNG over a satellite image using alpha channels
> and transparency, add text with TTF font, with "Portuguese characters" and
> use the image area completely, with no blanks in the sides.
>
> The point is: is it possible to add this grads extension, to handle GrADS
> metafile?
>

Yes, the gxyat extension extracts the metafile instructions and renders it
using cairo (from C). The idea is to add a function to IPC that grabs the
metafile instructions and writes it to stdout so that the extensions can
handle it. In PyGrADS I'd like to render it with Matplotlib on top of a blue
marble basemap or a satellite image (the PyGrADS screenshots are plotted
exclusively with Matplotlib). Now, gxyat can write SVG which cairo can
handle (of course, cairo wrote it) so this could be a viable initial path to
get the GrADS vector graphics instructions into PHP.


>
>> One question: does PHP have any way of efficiently representing numerical
>> arrays?
>>
>>
> If you are asking about n dimensional arrays, lists, vectors and things
> like these the answer is yes. Its not hard to work with it but I really dont
> know if there is a limit to the size of objects or something like it. But
> its easy to implement.
>

Perl and Python also have "arrays" but these are really "lists" and are very
inefficient for numerical work. PDL in perl and numpy in Python are
extensions for efficient handling of numerical n-dimensional arrays. Does
PHP have anything similar?


>
> I just subscribed to opengrads-devel list and I saw that you are working on
> a Matlab interface. Do you know if someone has ever tried to do a "R" (<
> http://www.r-project.org/>) interface? I used to work on it and its a very
> useful environment.
>

Funny that you ask. I was looking into R yesterday. However, I found out
that I could use R from Python using the Rpy extension. It seems to work
well on my Mac. One might be able to develop a native R interface to GrADS
but I do not know much about R internals myself, and the python route works
me. If you have any interest, go for it.


>
> By the way, there is something off-topic that I'm curious about: your name
> looks like a Portuguese-like name. Are you from Brazil or Portugal? Have you
> ever been here in Brazil? There are lots of people from here in the GrADS
> user list, specially in CPTEC, where I used to work. You may know José
> Pesquero, he is a heavy user from the GrADS list and a friend of mine.
>

Yes, I am from Niteroi and visited CPTEC many times. I helped them implement
PSAS for both regional and global data assimilation. Yes, I know Pesquero
for some time.

BTW, Pedro invited me for a round table this summer at CBMET, so I might be
coming to Sao Paulo in August.

   Cheers,

       Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] OpenGrADS development - PHP interface

[Arlindo da S. <da...@al...>]

On Tue, Jun 24, 2008 at 11:46 PM, Luiz Rodrigo Tozzi <
lui...@gm...> wrote:

> Hi Arlindo
>
> After reading the Gerl code and using it, I managed to translate the
> idea from Perl to PHP.


This is very nice! You got something already very functional.


> PHP is a bit different from Perl because there
> is no prompt to deal with PHP commands, only the interpreter of the
> command line or the web based interpreter.
>

Even in perl, most times I just write a script.


>
> I began to write the PHP interface and now I can open the grads with
> the -u option, with bidirectional pipe. Some of the most common used
> commands are implemented. For an example:
>

[...]


> I'm preparing the code to the Echo/Verb style you did in the Gerl and
> I can send you this first version of the code for you to have a look.
>

These get really important for debugging. In batch sometimes one wants to
suppress most output except when something goes wrong.


>
> Is there something I forgot for this first pre-alpha prototype? I'm
> open for sugestions!
>

 I see that you started with a non-OO prototype. The main advantage of an OO
interface is that you can instantiate more than one version of GrAS at a
time. For example when dealing with HDF and OPeNDAP files in v1.9 one end up
having to start 2 instances (one with gradshdf, another with gradsdods).
Another advantage of an OO approach is that it makes it easy to extended it
n different directions, while retaining the core functionality in a base
class.


>
> I'm interested in handling the graphical output of GrADS through GD
> but I don't know how to do it. I used to deal with GD programming in
> PHP but i don't know how it works in GrADS.
>


I am not clear exactly what kind of things would you like to do. You can
always write PNG from GrADS and read it from disk. You could also capture
the GrADS metafile through the pipe (I'd need to add an simple grads
extension for that) and then use GD interface to PHP to create the image in
PHP. (I'd recommend cairo over GD as it is more capable.)

One question: does PHP have any way of efficiently representing numerical
arrays?

   Again, congratulations! This is very exciting work. I look forward to
distribut it through opengrads as another interface to GrADS. Perhaps we
could start checking in to the repository what you already have.

  Cheers!

      Arlindo


---- original message ----

Hi Arlindo

After reading the Gerl code and using it, I managed to translate the
idea from Perl to PHP. PHP is a bit different from Perl because there
is no prompt to deal with PHP commands, only the interpreter of the
command line or the web based interpreter.

I began to write the PHP interface and now I can open the grads with
the -u option, with bidirectional pipe. Some of the most common used
commands are implemented. For an example:

#!/usr/bin/php
<?php
include ("gradsPHP.php");

// OPEN GRADS WITH OR WITHOUT OPTIONS
grads(array(
 "Bin" => "gradsnc",
 "Echo" => "0",
 "Opt" => "-b"
 ));
// or just grads();

// OPEN THE FILE
ga_open("model.nc","nc");

// SET LAT, LON, ETC
ga_set("lat","-23.8 -12.6");
ga_set("lon","-52.2 -39.4");
ga_set("gxout","shaded");
ga_set("grads","off");

// DISPLAY PS
ga_display("ps");

// DRAW THE TITLE CONTROLLING THE POSITION OF THE TITLE
ga_title("Pressao - Minas
Gerais",$opt=array("Font"=>"0","Size"=>".25","YOffset"=>".2"));

// CBARN AND SHAPE CONTOURS
ga_cmd("run cbarn.gs");
ga_set("line","0");
ga_cmd("shp_lines est");
ga_cmd("shp_lines mun");
//ga_query("pos");

// EXPORT THE IMAGE
ga_gxyat("ok.png");

// CLOSE PIPES, PID...
ga_submit();

// SHOW THE IMAGE
`animate ok.png`;

?>

This is a "tutorial like program", where I used the gradsPHP.php
functions that arrange the commands and send them to grads through the
pipe.

I create the ga_title() function based in Jennifer's title.gs script,
but in this case you can pass some attributes through an array of
options, including the Y position of the title. I obtain this
information using the "q gxinfo" and retriving the output using the
pipe system.

The ga_cmd() function is the most generic function of the class. It
can send the commands like:

ga_cmd("set x 1");
ga_cmd("set y 1");
ga_cmd("d ps");
ga_cmd("draw title something");

or

ga_cmd("
set x 1
set y 1
d ps
draw title something
");

or even

ga_cmd($scriptgs);

[$scriptgs is the content of a gs file]


I'm preparing the code to the Echo/Verb style you did in the Gerl and
I can send you this first version of the code for you to have a look.

Is there something I forgot for this first pre-alpha prototype? I'm
open for sugestions!

I'm interested in handling the graphical output of GrADS through GD
but I don't know how to do it. I used to deal with GD programming in
PHP but i don't know how it works in GrADS.


Peace!

--

Luiz Rodrigo Lins Tozzi
lui...@gm...

-- 
Arlindo da Silva
da...@al...