On Dec 18, 2006, at 10:00 AM, Ed Hill wrote:
On Mon, 18 Dec 2006 07:48:52 -0700 Ed Hartnett <ed@xxxxxxxxxxxxxxxx>
wrote:
Jeff Whitaker <jswhit@xxxxxxxxxxx> 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@xxxxxxx | 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
==============================================================================
