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

ENH: Discuss inclusion of a CMake build #356

Open
wants to merge 49 commits into
base: main
Choose a base branch
from
Open

Conversation

Patol75
Copy link
Contributor

@Patol75 Patol75 commented Jun 18, 2022

I am opening this PR to discuss a possible addition of a CMake build to Fluidity as an alternative to Autotools.
The main motivation is the deprecation by CMake of the command-line argument --find-package (more details here) that was used in #125 to fix #113. This deprecation complicates building against recent VTK libraries using Autotools. Overall, it might be valuable to support CMake to avoid such issues, even though it is not impossible it brings issues of its own.

I will write the content of the PR later using the tree of file changes GitHub provides, summarising the changes I have made building on @jrper original build described in #115.

By no means the present PR should be merged as-is. If a CMake build is to be included in Fluidity, changes from this branch will likely be ported to another branch through targetted commits.

Useful URLs:

Patol75 and others added 30 commits February 28, 2022 11:33
There were a few assumptions about where the CMake build was
being initiated from -- we should support the usual workflow
of 'mkdir build && cd build && cmake ..'. In some ways it's not
ideal that we output pre-processed files into the original source
tree, but that's a problem for later.
The h5hut CMake build was making a few assumptions about being
invoked within an autotools context (config.h, directory layout),
but here it should be possible to build either as a CMake
subproject or within autotools.
…nd/libspud; Remove some further unused variables; Misc changes.
@Patol75 Patol75 added enhancement help wanted feedback needed WIP work-in-progress PRs that are known to be not ready for merge labels Jun 18, 2022
@Patol75
Copy link
Contributor Author

Patol75 commented Jun 20, 2022

Given the massive changes included in the present branch, I have pushed another branch, called cmake_build_2022_minimal, which only contains a minimal changeset to allow for a CMake build and unit tests to successfully complete. Changes can be found here, and the associated successful Actions run here.

To summarise the changes, there is now a CMakeLists.txt file within most of Fluidity's sub-directories that contain source files. Additionally, Python packages are now installed in the user site-packages directory and can be accessed within the Python interpreter without having to set the PYTHONPATH environment variable.

Steps to build Fluidity from a fresh Jammy 22.04 installation are detailed in docker/Dockerfile.jammy. Packages are downloaded from the official Ubuntu package repositories using the latest versions available (e.g. VTK 9.1), except for GMSH and PETSc. The former is downloaded from the official website as a pre-built binary, while the latter is first cloned from the official release branch hosted on GitLab and then built.

Configure- and build-time instructions are mostly found in the CMakeLists.txt file at the root of Fluidity's directory. Programs/packages marked as required include HDF5, MPI, NetCDF, PETSc, Python 3, sed, TCMalloc, UDUNITS and VTK. Additionally, a few libraries are fetched over the network: libspatialindex is downloaded from the official GitHub repository and seamlessly integrated into Fluidity's build as it also uses CMake, while Judy and Zoltan are downloaded from their respective SourceForge and GitHub repositories and built according to provided instructions. The only environment variables required to be set by the user are PETSC_ARCH and PETSC_DIR.

Questions, comments, feedback and suggestions are all very much welcomed.

@angus-g
Copy link
Contributor

angus-g commented Jul 1, 2022

Thanks for your work on this! I recommend switching the PR to the minimal branch, because this one is impossible to do a meaningful review on. I do think that having a CMake build system available is worthwhile, even just to avoid make makefiles!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

VTK library name changes
2 participants