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

Cmake #487

Open
wants to merge 8 commits into
base: develop
Choose a base branch
from
Open

Cmake #487

wants to merge 8 commits into from

Conversation

LecrisUT
Copy link
Contributor

This PR contains both the CMake implementation and CI reorganization. We can split it up later, but lets keep them together until the CI pass

@LecrisUT LecrisUT mentioned this pull request Feb 21, 2024
Copy link
Contributor Author

@LecrisUT LecrisUT left a comment

Choose a reason for hiding this comment

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

@JeromeCCP9 Here's the re-implementation. I have left a few comments

jobs:
tests:
name: Check on ${{ matrix.toolchain }} toolchain ${{ matrix.mpi }}
runs-on: ${{ matrix.os || 'ubuntu-latest' }}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is no macos and windows here, because we need to discuss what compilers to use there and where to get them

Comment on lines +12 to +17
LANGUAGES Fortran C
)

set(CMAKE_C_STANDARD 11)
set(CMAKE_C_STANDARD_REQUIRED ON)
set(CMAKE_C_EXTENSIONS OFF)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are some new C sources, but header only? Probably we don't need to add C to the main project in that case.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Adding C is useful for compiling with MKL, without this cmake cannot detect MKL automatically
https://cmake.org/cmake/help/latest/module/FindBLAS.html#intel-mkl

It is a bit annoying since we are actually a fortran code, but without this users need to define a lot of cmake variables for MKL.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What about using find_package(MKL) by default if it's intel compiler, otherwise have an option WANNIER90_MKL option that uses either MKL or default BLAS/LAPACK? I am not sure if it works on a pure Fortran project, but we can try and see

Copy link
Collaborator

Choose a reason for hiding this comment

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

Did a test, we can add some if conditionals to find either MKL or BLAS/LAPACK, however, in the

target_link_libraries(Wannier90_lib PRIVATE
        BLAS::BLAS LAPACK::LAPACK)

I guess we need to add another if for MKL as well, not sure if there is a simpler solution.

On the other hand, by enabling C language everything works automatically.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, I suggest we postpone the decision of using either implementation, because @giovannipizzi warned me that there is an issue between LAPACK and macos, which we need to think how to handle.

@@ -0,0 +1,179 @@
cmake_minimum_required(VERSION 3.25...3.29)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have upgraded the minimum CMake to be in sync with CentOS stream 9 (should be ported to RHEL 9, I'll try to make some noise on that) and Ubuntu 24.04. Users could use pip install cmake and HPCs should get ready.

Comment on lines +16 to +20
#[=============================================================================[
# Options #
]=============================================================================]

#[=============================================================================[
# Project configuration #
]=============================================================================]
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Placeholders for if we want to add coverage and sanitizer

test-suite/CMakeLists.txt Outdated Show resolved Hide resolved
@LecrisUT
Copy link
Contributor Author

It seems the only failing tests are with ifx, should we change it to ifort and try again, or mark it as experimental for now.

@@ -0,0 +1,7 @@
cmake_minimum_required(VERSION 3.25...3.29)
project(demo_Wannier90 LANGUAGES Fortran)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here are functional tests for the library. Let me know what things to test in these cases.

@LecrisUT
Copy link
Contributor Author

@JeromeCCP9 There are a few issues with the demo.F90 interface using different variable types. It is also a bit confusing how to deal with mpi_comm being integer in the module file if it's built without mpi. Other than that, the C/C++ interface seems to fail with: undefined reference to symbol 'CFI_establish@@GFORTRAN_9'. Could you assist me with these?

@LecrisUT LecrisUT mentioned this pull request Feb 22, 2024
@JeromeCCP9
Copy link
Collaborator

Yes, I'll attend to these, let me catch up this evening...

@JeromeCCP9 There are a few issues with the demo.F90 interface using different variable types. It is also a bit confusing how to deal with mpi_comm being integer in the module file if it's built without mpi. Other than that, the C/C++ interface seems to fail with: undefined reference to symbol 'CFI_establish@@GFORTRAN_9'. Could you assist me with these?

@JeromeCCP9
Copy link
Collaborator

This last week I've made some changes to the library and provided a new test driver for the c++ interface in a branch "c-for-gc," and these will be merged shortly into develop. I think that the existent tests must be replaced (by me), so it would make more sense to remove the demo.F90 tests from this PR, if possible? If not, then I merge later, that's also ok.

(Also, at the moment, the c++ interface relies on a f2018 support (for CFI_establish) and this needs to be tested for.)

@LecrisUT
Copy link
Contributor Author

This last week I've made some changes to the library and provided a new test driver for the c++ interface in a branch "c-for-gc," and these will be merged shortly into develop. I think that the existent tests must be replaced (by me)

I saw that, it's ok, just ping me and I will rebase and fix that.

remove the demo.F90

It would be good to have a Fortran test. In #444 I am mocking up a packaging test that would at least do a smoke test.

(Also, at the moment, the c++ interface relies on a f2018 support (for CFI_establish) and this needs to be tested for.)

Do we need specific flag to enable it?

Comment on lines +53 to +60
set(CMAKE_INSTALL_MODULEDIR ${_DEFAULT_CMAKE_INSTALL_MODULEDIR}
CACHE STRING
"Fortran module installation path (Not a cmake native variable)"
)
cmake_path(IS_ABSOLUTE CMAKE_INSTALL_MODULEDIR _is_absolute)
if (_is_absolute)
set(CMAKE_INSTALL_FULL_MODULEDIR ${CMAKE_INSTALL_MODULEDIR})
else ()
Copy link

@MehdiChinoune MehdiChinoune Jun 10, 2024

Choose a reason for hiding this comment

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

It's not a good idea to use CMAKE_ prefixed variables (To avoid a possible future conflict).
I think WANNIER90_INSTALL_MODULEDIR is better.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fully aware of that. The issue is that CMake install support for Fortran has not been implemented and these are a bit tricky because these are ABI dependent and there is no discussion on how it should be designed. This path is also one that should be common among all dependencies, thus the preference of CMAKE_ variable.

Currently this is made compatible with fortran-stdlib in hopes that there can be convergence towards that.

Comment on lines 1 to 9
prefix: @CMAKE_INSTALL_PREFIX@

Name: wannier
Version: @PROJECT_VERSION@
Description: @PROJECT_DESCRIPTION@
URL: @PROJECT_HOMEPAGE_URL@

Cflags: -I@CMAKE_INSTALL_FULL_MODULEDIR@ -I@CMAKE_INSTALL_FULL_INCLUDEDIR@
Libs: -L@CMAKE_INSTALL_FULL_LIBDIR@ -lwannier90

Choose a reason for hiding this comment

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

Suggested change
prefix: @CMAKE_INSTALL_PREFIX@
Name: wannier
Version: @PROJECT_VERSION@
Description: @PROJECT_DESCRIPTION@
URL: @PROJECT_HOMEPAGE_URL@
Cflags: -I@CMAKE_INSTALL_FULL_MODULEDIR@ -I@CMAKE_INSTALL_FULL_INCLUDEDIR@
Libs: -L@CMAKE_INSTALL_FULL_LIBDIR@ -lwannier90
prefix: @CMAKE_INSTALL_PREFIX@
libdir: ${prefix}/@CMAKE_INSTALL_LIBDIR@
includedir: ${prefix}/@CMAKE_INSTALL_INCLUDEDIR@
moduledirL: ${prefix}/@WANNIER90_INSTALL_MODULEDIR@
Name: wannier
Version: @PROJECT_VERSION@
Description: @PROJECT_DESCRIPTION@
URL: @PROJECT_HOMEPAGE_URL@
Cflags: -I${moduledir} -I${includedir}
Libs: -L${libdir} -lwannier90

Using full paths make it unrelocatable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed, there was some context for this, but I completely lost it. Maybe it was related to testing the pkg-config file in the integration tests since the file in the build directory is not usable. Really don't remember why I made it like that.

There are more issues there though because PUBLIC linked libraries are not included. In principle this should be written as:

file(GENERATE OUTPUT wannier.pc.in INPUT wannier.pc.in.in)
configure_file(${CMAKE_CURRENT_BINARY_DIR}/wannier.pc.in wannier.pc)

And use a gen-ex depending on the target property to get the -l/-L/-I flags needed there. Didn't get the time to investigate what are appropriate flags for it though, would appreciate some help/discussion on this.

This is necessary because of the use mpi_f08 that is conditionally used in the Fortran module api.

Copy link

@MehdiChinoune MehdiChinoune Jun 10, 2024

Choose a reason for hiding this comment

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

You could add a new string variable WANNIER_LINK_LIBRARIES and add any library wannier is linked to. then add Requires: @WANNIER_LINK_LIBRARIES@ to wannier.pc.in file.
but WANNIER_LINK_LIBRARIES should contain the names of their .pc files.

Copy link
Contributor Author

@LecrisUT LecrisUT Jun 10, 2024

Choose a reason for hiding this comment

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

The question is where do we get the values to construct it? If we figure out that, I can write a prototype to be more templatable.

These values are taken from targets like MPI::MPI_Fortran. We can investigate that is populate in there with things like: https://stackoverflow.com/a/34292622. It should be in an *_INTERFACE_* like property. But maybe target Wannier_lib should be used to check that instead

CMakeLists.txt Outdated Show resolved Hide resolved
Signed-off-by: Cristian Le <cristian.le@mpsd.mpg.de>
Signed-off-by: Cristian Le <cristian.le@mpsd.mpg.de>
Signed-off-by: Cristian Le <cristian.le@mpsd.mpg.de>
Signed-off-by: Cristian Le <cristian.le@mpsd.mpg.de>
Signed-off-by: Cristian Le <cristian.le@mpsd.mpg.de>
Signed-off-by: Cristian Le <cristian.le@mpsd.mpg.de>
Signed-off-by: Cristian Le <cristian.le@mpsd.mpg.de>
Signed-off-by: Cristian Le <cristian.le@mpsd.mpg.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants