Full version number contained in install path?

[awvwgk]

What is the expected ABI compatibility of json-fortran versions?

The soversions sets major.minor, however the full version number is included in the install path, which disallows to use the major.minor version compatibility and since an RPATH now must contain the full version number (major.minor.patch).

$PREFIX
└── jsonfortran-gnu-8.2.5
    ├── cmake
    │   ├── jsonfortran-gnu-config-version.cmake
    │   ├── jsonfortran-gnu-config.cmake
    │   ├── jsonfortran-gnu-targets-release.cmake
    │   └── jsonfortran-gnu-targets.cmake
    └── lib
        ├── json_file_module.mod
        ├── json_kinds.mod
        ├── json_module.mod
        ├── json_parameters.mod
        ├── json_string_utilities.mod
        ├── json_value_module.mod
        ├── libjsonfortran.a
        ├── libjsonfortran.so -> libjsonfortran.so.8.2
        ├── libjsonfortran.so.8.2 -> libjsonfortran.so.8.2.5
        ├── libjsonfortran.so.8.2.5
        └── pkgconfig
            └── json-fortran.pc

[awvwgk]

I decided to follow the suggested ABI compatibility from the soversion for conda-forge packaging: https://github.com/conda-forge/staged-recipes/pull/17555

[jacobwilliams]

I don't fully understand what you are asking. :)

[awvwgk]

I'm trying to link dynamically via RPATH. A project depending on jsonfortran might define -Wl,-rpath,'$ORIGIN/../jsonfortran-gnu-8.2.5/lib'. However, since the RPATH contains the version number there is no way to upgrade from from 8.2.5 to 8.2.6 without breaking the dependent project in the same installation prefix, i.e. there is no more advantage from dynamic linking anymore. I could set LD_LIBRARY_PATH via a module file, but I prefer not to.

I found that I can use the GNU install conventions via an option, which solves the issue for me.