netcdf: Request: Add static library libnetcdf.a to build

[anowacki (Andy Nowacki)]

The majority of library ports that I have installed, but admittedly not all, seem to build and install both a static and dynamic version of the library. This is based on:

$ ls /opt/local/lib/lib*.{a,dylib} |
    awk -F. '!/lib.*\..*\.dylib/ {lib[$1]++}
    END {for (l in lib) if (lib[l] > 1) {
        print l, "yes"; n++
    } else {
        print l, "no"; m++
    }
    print "\n"n, "of", n+m, "have static libraries"}'

Quite a few codes that I use, one example being SEATREE (​http://geosys.usc.edu/projects/seatree/wiki/), seem to want to enforce static linking (presumably for executable portability or 'performance'), and so will not use a dynamic library. Would it be possible for the NetCDF port to create a static library?

I apologise for not offering a patch for this, but my brain is not big enough to deal with CMake. I understand this is probably low priority, but I for one would find building a static library very useful, and it hopefully would be fairly trivial. I note that the netcdf-fortran port does build the static library, as does hdf5, which prompted me to believe the suggestion might be feasible. Please let me know if I can help in any way.

[tenomoto (Takeshi Enomoto)]

hdf5 and netcdf-fortran are configured with traditional autotools and have enable-shared and enable-static options. netcdf uses CMake and the upstream developers offer a switch BUILD_SHARED_LIBS to build either shared (ON) or static (OFF). It is possible to build both by conducting configure and build phases twice, but it will complicate Portfile, which I don't like to do. You can ask the upstream developers to add an option to build both. However, I could easily add a static variant, which does not install shared libraries with the current CMakeLists.txt.

[anowacki (Andy Nowacki)]

I understand the desire to keep the portfile simple, and I've submitted a request to UCAR for dual-building of shared and static libraries, so we'll see what happens there. It seems BUILD_SHARED_LIBS doesn't preclude building both at once, but the machinery isn't in place and I agree it's better for this to come from upstream.

However, I could easily add a static variant, which does not install shared libraries with the current CMakeLists.txt.

Presumably this '+static'(?) variant would conflict with the default, and so it would be a binary choice between having the static or dynamic libraries? In that case, I think it's probably not worth maintaining that for the sake of some recalcitrant software that won't do dynamic linking, as I wouldn't choose the static variant over the dynamic one.

Thanks for explaining all that, though.

[ryandesign (Ryan Carsten Schmidt)]

Replying to tenomoto:

netcdf uses CMake and the upstream developers offer a switch BUILD_SHARED_LIBS to build either shared (ON) or static (OFF). It is possible to build both by conducting configure and build phases twice, but it will complicate Portfile, which I don't like to do. You can ask the upstream developers to add an option to build both.

As you say, cmake in general does not support building both static and dynamic libraries at the same time; you must choose one or the other, and we certainly choose dynamic libraries in MacPorts. If the developers of netcdf can add to their cmake files to make building and installing both possible for netcdf, that's fine; we can then update the port to use that. I'm not sure if anybody has tried to contact them yet to suggest that or if they are interested in doing that.

If we want to develop a general-purpose solution that could be applied to any cmake-using port that does not have specific upstream support for this, it should go into the cmake-1.1 portgroup. But I don't know if we want to put that much effort into it, since using static libraries is not the best idea on macOS and we especially need to encourage that practice.

However, I could easily add a static variant, which does not install shared libraries with the current CMakeLists.txt.

You should not add such a variant, because if the user installs the port with this variant, it will break any other port the user has installed (or later receives a binary of from our packages server) that links with the dynamic library.

I suggest that this ticket should be closed as "wontfix" and the reporter should work with the developers of the software he wants to use so that they work with netcdf's dynamic libraries.