Upgrade bundled netCDF to version 4.6.2 #2035
Conversation
It looks like they now break the distribution up by language, so I grabbed the C version.
Note: this may longer be necessary, since the docs say the constant is not enforced after 4.5.0.
This may need to be updated if we see build products showing up as untracked files.
Apparently the AS_CASE statement I tried to use was wrong, probably because it was wrapped in an m4 command. I think we can avoid this anyway though, since libmesh already requires automake 1.16
I am trying to work around the following error during configure:
config.status: error: Something went wrong bootstrapping makefile fragments
for automatic dependency tracking. Try re-running configure with the
'--disable-dependency-tracking' option to at least be able to build
the package (albeit without support for automatic dependency tracking).
More information about this issue can be found here:
https://www.gnu.org/software/automake/manual/html_node/Dependencies.html
Automatic dependency tracking can be suppressed by putting
no-dependencies in the variable AUTOMAKE_OPTIONS, or passing
no-dependencies as an argument to AM_INIT_AUTOMAKE (this should be the
preferred way). Or, you can invoke automake with the -i
option. Dependency tracking is enabled by default.
This puts in place our changes to configure.ac
|
+400k, -350k 🙄 If we have to start updating netCDF more often, we might be better off making it into a git submodule. |
|
That's some serious code - I guess you can take the rest of the year off! |
|
@pbauman, I've pasted the GRINS failure below. Somehow one of the files in the netCDF source dir gets a local modification: Would it be possible for you to log in there and tell me what the diff is? I don't see it on my local system and it's possible the file in question shouldn't even be under source control if it is meant to be a generated file or something... |
|
Yeah, sure enough it says that file is generated: Hopefully it's generated during configure and not bootstrap. I will check on this. |
|
@pbauman I'm also curious if you know how the dbg target could have passed even though the devel target failed? I'm unable to click on the "Details" links at the moment (femputer timeout) so I'm not exactly sure what the differences are between the two recipes. |
@jwpeterson No idea. There should be no difference in that step (literally calling the same script in that step of both recipes). I've restarted femputer and redelivered the last push you did so it'll rerun in a bit and we can see. |
Thanks, seems to be working again! |
|
This passes all the tests and doesn't appear to have broken anything new in "make distcheck" according to my local testing, so I'm going to go ahead and merge. There were a few other issues with the distcheck target, however, so I will be opening a separate PR for that. |
While experimenting with reading Exodus files written in netCDF4 format in Python, we ran across some issues with h5py that seemed to be related to UTF-8 encodings. While looking through the netCDF release notes, I came across this issue related to UTF-8/netCDF4:
Unidata/netcdf-c#298
Which was apparently fixed by this PR:
Unidata/netcdf-c#316
And that made it into netCDF release 4.5.0-rc1 (June 5, 2017):
https://www.unidata.ucar.edu/software/netcdf/docs/RELEASE_NOTES.html
Since our current netCDF 4.4.1.1 predates this release, it seems that netCDF4 files we write are affected by this bug. Following roughly the same update procedure as @benkirk did for the 4.4.1.1 update, I was able to update to 4.6.2 locally without too much difficulty.
I don't think this needs to go in our v1.4.0 release, but if there is enough demand for it we can always release a v1.4.1, similar to what was done for v1.2.1.