Versions in library names?

[edwardhartnett]

I see the built libraries have a version number in the name: libbacio_v2.2.0_4.a

This is pretty non-standard and requires that all using build systems change each time a new release is made of any of these libraries.

Has there been discussion of moving to a more standard naming, where the library would be called libbacio.a?

[kgerheiser]

Yes, this has been brought up. I (and others) don't like how the version is appended to the end of the library name.

It is done this way to keep it consistent with the way the libraries are currently installed for NCO. So, we just decided to keep it like this for public release as well. In the future we'd like to move it to a more sane naming scheme.

[aerorahul]

wouldn't it make sense to keep this issue open until a resolution is reached. Once it is closed and disappears, it will be hard to keep this in mind.

[kgerheiser]

My idea for the next release is to A. remove the version names, and B. instal each library in its own folder rather than in one big /lib

[edwardhartnett]

The install should be determined by CMake. That is, if the user has built NCEPLIBS with CMake and set CMAKE_INSTALL_PREFIX, then that's where the library should be installed. The default should be /usr/local/lib.

In general, most users are going to want all the NCEPLIBS in one directory. Each install directory has to be passed into the build somehow, so having each library in a different directory would be harder.

[aerorahul]

The install should be determined by CMake. That is, if the user has built NCEPLIBS with CMake and set CMAKE_INSTALL_PREFIX, then that's where the library should be installed. The default should be /usr/local/lib.

In general, most users are going to want all the NCEPLIBS in one directory. Each install directory has to be passed into the build somehow, so having each library in a different directory would be harder.

@edwardhartnett That philosophy works well for system libraries. In development environment, where we often have multiple versions of the NCEPlibs, this paradigm breaks. These libraries are often loaded by modules (on HPC's and increasingly even on linux workstations/macs). We are hoping to keep both options. Those who want to keep all the libraries together can still do so, while those who want to keep them arranged by library and version, can do so as well.

[edwardhartnett]

The existing CMake system already allows for both. You simply need to respect CMAKE_INSTALL_PREFIX.

In that way, complex installs, which need multiple versions, can be installed in numerous directories with whatever local naming scheme suits the local sysadmins.

Simple users, like the lone scientist installing UFS on a linux workstation, will just dump everything in one directory.

[aerorahul]

@edwardhartnett you are correct CMAKE_INSTALL_PREFIX should be respected. Scripting will be required, to make that variable change from library to library when having segregated installations. We can shelve this discussion till it is actually picked up for work again.

[kgerheiser]

This has been fixed in the develop branch of all libraries