Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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? wtWarren: 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. -JeffNetCDF 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 owncfortran.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 toeschew 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 projectsSince 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. Somost 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 upstreamproject so that everyone can benefit. If its possible [0], I would urgethe 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 ==============================================================================
netcdfgroup archives: