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.

Sign up for GitHub

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

Jump to bottom

CMake installs under unexpected package name #579

Open
EmilyBourne opened this issue Aug 21, 2024 · 3 comments · May be fixed by #580
Open

CMake installs under unexpected package name #579

EmilyBourne opened this issue Aug 21, 2024 · 3 comments · May be fixed by #580
Labels
CMake

Comments

@EmilyBourne
Copy link
Contributor

According to the README json-fortran can be used in a CMake project by linking the library jsonfortran::jsonfortran or jsonfortran::jsonfortran-static:

json-fortran/README.md

Line 151 in cde2620

target_link_libraries ( ${TEST} jsonfortran::jsonfortran-static )

However the installation means that a different name library name is used for every installation. This comes from here:

json-fortran/CMakeLists.txt

Lines 111 to 114 in cde2620

# Set the package name to be specific to the compiler used, so that
# versions compiled with different compilers can be installed in parallel
string ( TOLOWER ${PROJECT_NAME}-${CMAKE_Fortran_COMPILER_ID} PACKAGE_NAME )
set ( PACKAGE_VERSION "${PACKAGE_NAME}-${PROJECT_VERSION}" )

The library names are therefore actually more like: jsonfortran-nvhpc::jsonfortran. This is particularly cumbersome as the compiler id in CMake is uppercase but the library uses lowercase.

As a workaround it is possible to use the documented name by doing:

# Get compiler dependent name
string(TOLOWER "jsonfortran-${CMAKE_Fortran_COMPILER_ID}" jsonlibname)
# Create alias
add_library(jsonfortran::jsonfortran ALIAS ${jsonlibname}::jsonfortran)

however it would be simpler if jsonfortran simply installed itself with the documented name
@EmilyBourne EmilyBourne linked a pull request Aug 21, 2024 that will close this issue
Open
@JorgeG94
Copy link

this will be good, I do some TOLOWER shenanigans to link to json-fortran in my cmake project, thanks for this!

@jacobwilliams
Copy link
Owner

jacobwilliams commented Aug 25, 2024 •
edited
Loading

Some thoughts on this and questions:

  • this would be a breaking change for CMake users right? They would have to update their cmake files? [I don't use Cmake with json-fortran so I don't know]
  • I think maybe putting the compiler name in there was so you could compile multiple versions for different compilers (note: in general you can't mix different fortran compilers since, e.g. the mod files are not compatible). Would this change make that impossible now?
  • If we do this: also check the https://github.com/conda-forge/json-fortran-feedstock to see if that would need to be changed for the conda package.
  • What is the convention for other Fortran libraries here? CMake files are mostly gibberish to me, it just seems like every library has different gibberish.

@EmilyBourne
Copy link
Contributor Author

Some thoughts on this and questions:

  • this would be a breaking change for CMake users right? They would have to update their cmake files? [I don't use Cmake with json-fortran so I don't know]

I think this is optional. It could be a breaking change or the documented name could be introduced as an alias. If it is an alias then both names would co-exist allowing users to choose whichever name is easier.

  • I think maybe putting the compiler name in there was so you could compile multiple versions for different compilers (note: in general you can't mix different fortran compilers since, e.g. the mod files are not compatible). Would this change make that impossible now?

This should still be possible. I am suggesting that you keep the command:

find_package ( jsonfortran-${CMAKE_Fortran_COMPILER_ID} )

which looks for a jsonfortran-GNU-config.cmake file. As long as there are different files for each compiler each file can contain different paths allowing the versions for different compilers to coexist. Once the library has been found though there should no longer be any reason to differentiate between the different versions. You will never use multiple versions of jsonfortran in the same project.

Currently your documentation claims that you no longer differentiate after locating the package but the implementation doesn't match the documentation and there are no existing CMake variables that make it easy to get the name of the loaded library. Hence the workaround (which is equivalent to what I am suggesting adding to jsonfortran directly)

I am not familiar with conda packages but I had a look through. I don't think anything would need to be changed there. This change should only affect users it will not affect which files are generated by json-fortran or how they are generated. It will just add a line to one of those files

  • What is the convention for other Fortran libraries here? CMake files are mostly gibberish to me, it just seems like every library has different gibberish.

Every other library that I have worked with (eg. MPI/HDF5) uses a library name like HDF5::HDF5 after loading. But the libraries that I am used to working with are larger, so the differentiation between versions is done in a FindHDF5.cmake. The solution with:

find_package ( jsonfortran-${CMAKE_Fortran_COMPILER_ID} )

seems like a good one to me. It is just strange to then have this affect the rest of the code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
CMake
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Correct CMake namespace to match documentation. EmilyBourne/json-fortran
3 participants
@jacobwilliams @EmilyBourne @JorgeG94