cfortran.h

[James Gallagher]

On Dec 18, 2006, at 10:00 AM, Ed Hill wrote:

> On Mon, 18 Dec 2006 07:48:52 -0700 Ed Hartnett <ed at unidata.ucar.edu>
> wrote:
>
>> Jeff Whitaker <jswhit at fastmail.fm> writes:
>>
>>> Warren Turkal wrote:
>>>> The cfortran.h file is in /usr/include on Debian systems after
>>>> installing the cfortran package. Does netcdf use a cfortran.h in
>>>> /usr/include instead of the one within the tarball when it is
>>>> available? If not, could you please change netcdf to do so for
>>>> beta5?
>>>>
>>>> wt
>>>>
>>> Warren:  Why?  What if it is broken, or out of date?  I'd rather
>>> netcdf use it's own cfortran.h, which it knows it can trust.
>>>
>>> -Jeff
>>
>> NetCDF includes it's own cfortran.h, which will be used in its build.
>>
>> Any cfortran.h on the system will not be used, it will be ignored by
>> netCDF. The netCDF fortran API looks for, and uses, its own
>> cfortran.h, not depending on it to be installed, or using it if it  
>> is.
>>
>> This is necessary: some modifications to netCDF's cfortran.h allow it
>> to be built on even more platforms than the original cfortran.h
>> allows.
>
>
> Hi folks,
>
> I can appreciate "both sides" of this issue!  :-)
>
> As a developer, its nice to sometimes use a locally included copy of
> some 2nd-party software since, that way, you know its there and you
> know exactly what version it is (inc. any changes you made to it).
>
> As a packager for Fedora I can appreciate why most distros try to
> eschew locally included copies of dependent software (usually  
> libraries)
> since they can be problematic:
>
>   1) security headaches (eg. that local copy of zlib that a
>      package includes is OLD and has known security holes which will
>      mean that an updated system-wide zlib package will totally fail
>      to fix your local problem)
>   2) unnecessary bloat
>   3) local copies are essentially "forks" which increase overall
>      maintenance costs and tend to slow the movement of fixes into
>      the respective upstream projects
>
> Since cfortran.h is not a library, I think its quite unlikely to  
> result
> in security problems.  And its a single file so not a lot of  
> bloat.  So
> most of the reasons against local inclusion are mooted.
>
> However, it would be a shame to maintain local improvements in the
> "netCDF version of cfortran.h" without submitting them to the upstream
> project so that everyone can benefit.  If its possible [0], I would  
> urge
> the netCDF folks to work with upstream so that everyone can benefit
> from any "netCDF local" cfortran.h improvements.

I second this! I've found that it's much easier to send improvements  
'upstream' than to maintain them myself. I've done this with curl/ 
libcurl and a few others.

James
>
> Ed
>
> [0] - Yes, this assumes that "upstream" projects are actively
>       maintained and receptive to patches.  Which is not always
>       the case...!  :-/
>
>
> -- 
> Edward H. Hill III, PhD  |  ed at eh3.com  |  http://eh3.com/

--
James Gallagher                jgallagher at opendap.org
OPeNDAP, Inc                   406.723.8663

==============================================================================
To unsubscribe netcdfgroup, visit:
http://www.unidata.ucar.edu/mailing-list-delete-form.html
==============================================================================