Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

netcdf #213

Merged
merged 3 commits into from
May 23, 2016
Merged

netcdf #213

merged 3 commits into from
May 23, 2016

Conversation

ocefpaf
Copy link
Member

@ocefpaf ocefpaf commented Mar 28, 2016

Sadly this package was renamed to libnetcdf in the default channel and I guess we should keep that to maintain compatibility.

This is an attempt to update the netcdf package to the latest version and compiled against conda-forge's hdf5.


:: Remove msvc redist files.
cd %LIBRARY_BIN%
rm msvc*.dll
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I never tried this recipe on Windows. @rgrout can you take a look please?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is weird to manually remove the dlls here. Maybe the NetCDF install step copied them in? If so, keep this removal. Otherwise, this is cruft.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These particular lines may not be needed anymore. I can't verify until I get my windows vm repaired.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. I am removing them.

set HDF5_DIR=%LIBRARY_PREFIX%\cmake

if "%ARCH%" == "64" (
set CMAKE_GENERATOR="Visual Studio 10 2010 Win64"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need something better here to build for the different MSVC versions. You should be able to use one of the two examples from https://github.com/conda/conda-build/wiki/Windows-recipe-patterns#using-cmake-with-visual-studio

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I will take a look at that.

@jakirkham jakirkham changed the title netcdf WIP: netcdf Mar 28, 2016
# https://www.unidata.ucar.edu/support/help/MailArchives/netcdf/msg11423.html
export LD_LIBRARY_PATH=$PREFIX/lib

./configure \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we bound to use configure here? I had a look at how unidata is testing. They also use a special docker image, but use cmake instead of configure.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we bound to use configure here?

Nope. We can try cmake

They also use a special docker image, but use cmake instead of configure.

I will give that a try later. Thanks!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, I know @groutr mentioned that he tried cmake to build hdf5 and had issues. The issues may also present themselves here so we should be careful. Personally, given hdf5 had issues, I prefer configure, at present.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really hoped GitHub would handle that link better. Anyways, he was seeing segfaults when using hdf5/h5py with Python when hdf5 was built with cmake. I prefer using configure to segfaults any day. If this situation is any bit similar here, then we would be wise to stick with what works.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakirkham Thanks for the heads-up. But it may be of use in sorting out the correct configure switches.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was weird, and I'm still not sure of the root cause. I'm curious as to why they recommend cmake, yet their official binaries appear to be still using ./configure.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's get a stable release out first and then people can play with adding cmake if they so desire. Sound good?

export LDFLAGS="-L$PREFIX/lib $LDFLAGS"

# https://www.unidata.ucar.edu/support/help/MailArchives/netcdf/msg11423.html
export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And if this is only needed for make check, maybe it should be
LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH make check (set LD_LIBRARY_PATH just for make check)
I don't think it should be set during make

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.

set INCLUDE=%LIBRARY_INC%;%INCLUDE%
set HDF5_DIR=%LIBRARY_PREFIX%\cmake

cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH=%LIBRARY_PREFIX% -DCMAKE_INSTALL_PREFIX:PATH=%LIBRARY_PREFIX% %SRC_DIR%
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cmake needs to be a build dependency for windows, I think.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not necessarily we do have cmake pre-installed on AppVeyor. Not sure what is the best way to go though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should use our cmake, no? Is there some reason not too?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

@ocefpaf
Copy link
Member Author

ocefpaf commented Apr 3, 2016

Note to self. I removed homebrew from this PR as a test and got:

checking whether the C compiler works... no
configure: error: in `/opt/conda/conda-bld/work':
configure: error: C compiler cannot create executables
See `config.log' for more details

Now I am testing the default channel gcc, but I am not sure that is the way we want to go here.

@ocefpaf ocefpaf force-pushed the netcdf branch 2 times, most recently from ddb61f4 to 7265e43 Compare April 3, 2016 23:41
- m4 # [unix]
- msinttypes # [win]
- cmake # [win]
- curl
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is curl used here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

netcdf depends on curl to support OPeNDAP.

@jakirkham
Copy link
Member

Might need something like this for Mac. Also, this.

@pelson
Copy link
Member

pelson commented Apr 4, 2016

What are we reviewing here @ocefpaf. Couldn't you just rename the package in the feedstock, and then rename that feedstock?

@ocefpaf
Copy link
Member Author

ocefpaf commented Apr 5, 2016

What are we reviewing here @ocefpaf. Couldn't you just rename the package in the feedstock, and then rename that feedstock?

We don't have a feedstock libnetcdf (nor netcdf). My name comment at the top was just a rant.

@dopplershift
Copy link
Member

So trying to use non-system libcurl sounds like hell on OSX. I can get further by specifying [not osx] in the meta.yml. I'm currently working around problems with System Integrity Protection on El Cap causing DYLD_LIBRARY_PATH to be ignored by shell scripts (https://developer.apple.com/library/mac/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html#//apple_ref/doc/uid/TP40016462-CH3-SW1); maybe Travis will work though?

@dopplershift
Copy link
Member

So how about we just use cmake and eliminate autotools? Because this works for build.sh on my OSX system:

#!/bin/bash

cmake -DENABLE_DAP=ON -DCMAKE_INSTALL_PREFIX=$PREFIX .
make
make install

and I can even get it to link against the conda-forge libcurl. I can also say that @WardF (the netCDF maintainer) uses cmake for building. With this script and temporarily removing the hdf4 dependency due to conda-forge/hdf4-feedstock#5, I can get a usable set of netCDF4 binaries.


make
# https://www.unidata.ucar.edu/support/help/MailArchives/netcdf/msg11423.html
eval ${LIBRARY_SEARCH_VAR}=$PREFIX/lib make check || cat ncdump/test-suite.log
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I made a mistake here. Please update this to || { cat ncdump/test-suite.log; exit 1; }.

@ocefpaf
Copy link
Member Author

ocefpaf commented May 21, 2016

Those commands were in reference to building the FORTRAN library...which is separate from the C-library. There's no way this can work--LIBS="-lnetcdf -lhdf5 -lhdf5_hl" is asking it to link against libnetcdf.so before we've even built it.

Yeah. That was some copy-and-pasta. I should not send PRs while attending a conference 😝

@ocefpaf
Copy link
Member Author

ocefpaf commented May 21, 2016

So how about we just use cmake and eliminate autotools?

@kmuehlbauer mentioned that at some point. (Sorry, but I cannot recall. We can give it a shot tomorrow.)

With this script and temporarily removing the hdf4 dependency due to conda-forge/hdf4-feedstock#5, I can get a usable set of netCDF4 binaries.

I have been thinking about that about that and I don't have a proper solution yet. We can:

  1. eliminate hdf4 ncdump/ncgen in the hdf4 recipe;
  2. clobber them in the libnetcdf recipe;
  3. avoid using hdf4 in the libnetcdf recipe;
  4. rename hdf4 version of those files.

I will try 2 tomorrow and see how it goes. If anyone have a better idea please let me know.

@kmuehlbauer
Copy link
Contributor

@ocefpaf 😁 I had almost forgotten that myself. It was at the beginning of this PR.
Unidata is also using some docker image and cmake to build the libnetcdf in github.com work flow. So this is worth a shot. And we surely can get advice from @WardF, if there will be some problems.

@dopplershift
Copy link
Member

dopplershift commented May 21, 2016

I don't think conda will let us clobber--my built netcdf4 package didn't have ncdump until I removed the conflict.

@ocefpaf
Copy link
Member Author

ocefpaf commented May 21, 2016

I would not rely on conda to clobber as conda does the right thing. I would
manually substitute one by the other in the recipe. (Actually the right
thing would be to raise an error ;-)

@ocefpaf
Copy link
Member Author

ocefpaf commented May 22, 2016

Testing cmake. Everything works locally but I do not know how to build static libs and shared with it. The docs mention that I should BUILD_SHARED_LIBS=OFF to get the static libs, but then we won't get the shared.

Also, there are a few additional options we may use. I need DAP and HDF4, but I have no idea if it is a good idea to enable the rest (JNA, MMap, PNetCDF, and NC-4 Parallel). @dopplershift do you need/recommend testing any of these features?

# Features
--------
NetCDF-2 API:           yes
HDF4 Support:           yes
NetCDF-4 API:           yes
NC-4 Parallel Support:  no
PNetCDF Support:        no
DAP Support:            yes
Diskless Support:       yes
MMap Support:           no
JNA Support:            no

@jakirkham
Copy link
Member

jakirkham commented May 22, 2016

Testing cmake. Everything works locally but I do not know how to build static libs and shared with it. The docs mention that I should BUILD_SHARED_LIBS=OFF to get the static libs, but then we won't get the shared.

That's fine do 2 loops for building. Once with BUILD_SHARED_LIBS=OFF and once with BUILD_SHARED_LIBS=ON. Make sure to clean each build.

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/libnetcdf, recipes/zlib) and found it was in an excellent condition.

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/libnetcdf) and found it was in an excellent condition.

@ocefpaf
Copy link
Member Author

ocefpaf commented May 23, 2016

That's fine do 2 loops for building.

I thought about it, but it sounded "wrong." Anyways... That worked for Linux and OS X 🎉

But Windows, that was working before, is failing now. Not sure what is going on.

(We can skip Windows and open an issue on the feedstock to solve it later.)

make
# ctest # Save some time.
make install

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd add a make clean here. Maybe even a make distclean if they have one.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done! (No make distclean btw.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Ah, ok.

@jakirkham
Copy link
Member

That's fine do 2 loops for building.

I thought about it, but it sounded "wrong." Anyways... That worked for Linux and OS X 🎉

We do it for ncurses and it works great. We should probably start doing it for fftw where this is actually recommended (instead we have copy-pasta).

That worked for Linux and OS X 🎉

🎉 🎉 🎉

But Windows, that was working before, is failing now. Not sure what is going on.

(We can skip Windows and open an issue on the feedstock to solve it later.)

Not sure either.

@ocefpaf
Copy link
Member Author

ocefpaf commented May 23, 2016

@jakirkham if you are OK with this let's merge and iterate in the feedstock. This PR is getting hard to follow.

@jakirkham
Copy link
Member

LGTM. Thanks @ocefpaf.

@jakirkham jakirkham merged commit ec587cf into conda-forge:master May 23, 2016
@jakirkham jakirkham changed the title WIP: netcdf netcdf May 23, 2016
@jakirkham
Copy link
Member

lol I should have renamed before merging. 😆 Oh well.

@ocefpaf
Copy link
Member Author

ocefpaf commented May 23, 2016

Thanks @jakirkham!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

9 participants