-
Notifications
You must be signed in to change notification settings - Fork 139
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
base: develop
Are you sure you want to change the base?
Cmake #487
Conversation
c1f6922
to
002bdab
Compare
There was a problem hiding this 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' }} |
There was a problem hiding this comment.
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
LANGUAGES Fortran C | ||
) | ||
|
||
set(CMAKE_C_STANDARD 11) | ||
set(CMAKE_C_STANDARD_REQUIRED ON) | ||
set(CMAKE_C_EXTENSIONS OFF) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
#[=============================================================================[ | ||
# Options # | ||
]=============================================================================] | ||
|
||
#[=============================================================================[ | ||
# Project configuration # | ||
]=============================================================================] |
There was a problem hiding this comment.
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
It seems the only failing tests are with |
@@ -0,0 +1,7 @@ | |||
cmake_minimum_required(VERSION 3.25...3.29) | |||
project(demo_Wannier90 LANGUAGES Fortran) |
There was a problem hiding this comment.
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.
388e5e4
to
7540c6f
Compare
@JeromeCCP9 There are a few issues with the |
d3eaa3d
to
bf954ab
Compare
Yes, I'll attend to these, let me catch up this evening...
|
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.) |
I saw that, it's ok, just ping me and I will rebase and fix that.
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.
Do we need specific flag to enable it? |
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 () |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
cmake/wannier90.pc.in
Outdated
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
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>
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