From: Arlindo da S. <da...@al...> - 2008-08-01 16:45:36
|
On Fri, Aug 1, 2008 at 12:08 PM, Patrice Dumas <per...@fr...> wrote: > On Fri, Aug 01, 2008 at 11:44:15AM -0400, Jennifer Adams wrote: >> 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. > Or even for v1.9; in going to the new libdap there have been API level changes that make it impossible to build against an old libdods. Being able to use an old libgadods with gcc-2.95 is just too much trouble and in my judgement, not worth it. > Indeed, but gcc 2.95 is very very old. With anything above you can > certainly (maybe with some stl implementation). Besides, grads doesn't > link against libdap, but against libncdap which has a far better binary > stability. and we can imagine that the binary compatibility will never > break, so this gives room for backward compatibility at the source level. > Except for the size of the binary, gradsdap appears just as stable as "grads" built with the vanilla netcdf. Do you have any evidence that it adds any performance penalty besides the start up time? Perhaps we could take a bold step: build just one grads which is nc-dap enabled; and have "gradsnc" built as an option for those who need it. One could certainly try it out and see if the users can live with a single grads. My guess is that it would work just fine. So, you just add a single switch --with-nc-dap (default) --without-nc-dap This would really simplify the build... Arlindo -- Arlindo da Silva da...@al... |