Repository navigation
[choice] CMake packages found from the installation prefix (forwarding files in lib/cmake) - #389
Open
trsxvz wants to merge 8 commits into
Conversation
…version> read by the CMake package
The installed MFrontGenericInterfaceConfig.cmake tested ENV{${TFEL_DIR}}
and ENV{${HDF5_DIR}}, i.e. the environment variable named by the value of
a variable that is empty in these branches, so the environment variables
TFEL_DIR and HDF5_DIR were never read and the build-time TFEL and HDF5
directories were always used. The branch on ENV{${VERSIONED_TFEL_HOME}}
was dead too: VERSIONED_TFEL_HOME was never defined by MGIS.
Decision: the environment variables are tested by name, and the name of
the versioned variable is built from the version of TFEL used to build
MGIS exactly as TFEL builds it in tfel-modules-common.cmake
(TFELHOME_<version> with '.' and '-' replaced by '_'), in a private
_VERSIONED_TFEL_HOME variable. Non-breaking: without these environment
variables the hints are unchanged, and the order of precedence of the
template (TFEL_DIR, ENV{TFEL_DIR}, TFELHOME, ENV{TFELHOME_<version>},
ENV{TFELHOME}) is kept.
Alternatives: dropping the versioned branch (it never worked), or reusing
the VERSIONED_TFEL_HOME variable that TFEL's own package files define,
which is only set once a TFEL package has been found, i.e. too late.
Review item: M-148
The only version file was installed as share/mgis/cmake/mgis-config-version.cmake,
a name that find_package never reads for the packages MFrontGenericInterface,
MFrontGenericInterface-c and MFrontGenericInterface-fortran, so every
find_package call with a version failed ("version: unknown") and
<package>_VERSION was never defined. It was also generated from VERSION,
a variable that is never set.
Decision: mgis_library writes and installs <name>ConfigVersion.cmake next to
<name>Config.cmake from PROJECT_VERSION, so the core, C and Fortran packages
all get one, and the orphan mgis-config-version.cmake is no longer
generated. The compatibility policy SameMinorVersion is kept: it is the one
of the previous file and of TFEL's version file (tfel.cmake), and the
libraries carry no SOVERSION while minor releases change the API (3.1
renamed Space.hxx). Non-breaking: find_package without a version is
unchanged, and requests of 3.1 or 3.1.0 now succeed.
Alternatives: SameMajorVersion (a request of 3.1 would then accept a later
3.x installation) or AnyNewerVersion, or keeping mgis-config-version.cmake,
which no package can read.
Review item: M-138
With enable-static=ON, MFrontGenericInterface-static did not receive the definitions of enable-exceptions, OpenMP::OpenMP_CXX (enable-openmp), MGIS_ADDITIONAL_LIBRARIES (TBB::tbb with enable-parallel-stl-algorithms) nor MGIS_ADDITIONAL_LINK_FLAGS (-fsycl, -stdpar): a program linked with the static library aborted on a contract violation where the shared library throws, and the static target did not carry TBB or OpenMP in its link interface. Decision: the four missing settings are added to the static target in the same blocks as the shared one, with the if(enable-static) branches already used for the other settings of this file. Non-breaking: nothing changes without enable-static, and the static library now follows the options of the build exactly as the shared library does. Alternatives: merging the shared and static settings into one loop over both targets (same result, larger diff, and the TFEL block needs its -static target selection anyway). Review item: M-140
…ed after MGIS_SUFFIX
With MGIS_APPEND_SUFFIX, the Python package and the Julia module were
installed in site-packages/mgis_ and julia/mgis_ whatever the suffix,
because MGIS_SUFFIX_FOR_PYTHON_MODULES and MGIS_SUFFIX_FOR_JULIA_MODULES
were never defined: two suffixed installations in the same prefix
overwrote each other's bindings. Besides, the modules of mgis.fenics
imported mgis.behaviour by its absolute name, which fails (or loads
another MGIS) once the package is renamed.
Decision: both variables are defined from MGIS_SUFFIX, with '.' and '-'
replaced by '_' as TFEL does for TFEL_SUFFIX_FOR_PYTHON_MODULES
(tfel-python-modules.cmake), in the if(MGIS_APPEND_SUFFIX) block of
mgis.cmake that already derives the suffixed CMake directory, so that
both the Python section and bindings/julia see them: MGIS_SUFFIX=3.2
gives the package mgis_3_2. The three modules of mgis.fenics import
behaviour relatively ("from .. import behaviour as mgis_bv"), which is
the same module for the unsuffixed package. Non-breaking: without
MGIS_APPEND_SUFFIX nothing changes, and with it the previous name mgis_
was not usable.
Alternatives: using MGIS_SUFFIX unchanged (a '.' or '-' is not valid in
a Python package name), or adding an option to keep the unsuffixed
name, as TFEL's unversioned-python-module-names (a new option).
Review item: M-130
… generator
With a multi-configuration generator (Visual Studio, Xcode, Ninja
Multi-Config), test_fortran_bindings and test_fenics_bindings used a
dedicated branch that was broken: the tests were not added to
build-tests, "CONFIGURATION ${conf}" was passed as arguments of the test
program (the keyword is CONFIGURATIONS), so each test was registered
once per configuration in every configuration, and set_tests_properties
received the environment as several values, so only the first one was
set (MGIS_TEST_BEHAVIOURS_LIBRARY and MGIS_TEST_MODELS_LIBRARY were
lost). The FEniCS branch also quoted MGIS_FENICS_TEST_DATA and pointed
it to a build directory without data.
Decision: the multi-configuration branches are dropped and the
single-configuration code is used with every generator, since
add_test(NAME ... COMMAND <target>) already resolves the executable of
the tested configuration. The C tests need no change: they have no
such branch, and the double PROPERTY of their Windows branches was
removed with the DEPENDS entries (M-153). Non-breaking: the tests
generated with a single-configuration generator are unchanged.
Alternatives: repairing the multi-configuration branches
(CONFIGURATIONS, one ENVIRONMENT list, add_dependencies), which keeps
a duplicate of the same code and the per-configuration test names.
Review item: M-129
…ke-packages-of-the-installation-environment-scripts-debug-flags-and-test-targets' into 370-cmake-packages-environment-variables-version-files-static-library-options-suffixed-modules-and-multi-configuration
The configuration files of the packages MFrontGenericInterface,
MFrontGenericInterface-c and MFrontGenericInterface-fortran are only
installed in share/mgis/cmake (share/mgis-<suffix>/cmake), a directory
that find_package never searches under a prefix: neither
CMAKE_PREFIX_PATH, <package>_ROOT nor an installation in a system prefix
found them, and each package needed <package>_DIR to be set by hand.
Decision: share/mgis/cmake stays the location of the package files, and
mgis_library also installs in lib${LIB_SUFFIX}/cmake/<package> (or
<package>-<suffix> with MGIS_APPEND_SUFFIX) a <package>Config.cmake and a
<package>ConfigVersion.cmake that include the real files by a path
relative to their own location, so that the installation stays
relocatable. Non-breaking: only new files are installed, the recipes and
solvers that set <package>_DIR to share/mgis/cmake keep working, and the
C and Fortran packages still find the core package next to them (HINTS
${CMAKE_CURRENT_LIST_DIR}).
Alternatives: moving the package files to lib*/cmake/<package> or
share/cmake/<package> with forwarding files left in share/mgis/cmake
(changes the layout seen by packagers and the HINTS between the
packages), forwarding files in share/cmake/<package> (an
architecture-independent place for files that name the libraries of
lib${LIB_SUFFIX}), or one share/MFrontGenericInterface/cmake directory
(never searched for the -c and -fortran packages).
Review item: M-147
…installed-in-sharemgiscmake-where-find_package-does-not-look # Conflicts: # bindings/python/mgis/fenics/nonlinear_problem.py
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
[AI-assisted]
/!\ : TO MERGE ONLY AFTER MERGING #371
[choice]: the location of the CMake packages is a layout decision for packagers; the option taken only adds files. This branch is based on the branch of #371, whose version files it forwards: until #371 is merged, the list of commits also shows its commits; the commit of this PR is the last one. This PR is left for review of this choice.
Fixes #382.
Decisions made
share/mgis/cmakestays the real location of the package files.mgis_libraryalso installs, inlib${LIB_SUFFIX}/cmake/<package>(or<package>-<suffix>withMGIS_APPEND_SUFFIX), a<package>Config.cmakeand a<package>ConfigVersion.cmakeof one line each, including the real file by a path relative to their own location (computed withfile(RELATIVE_PATH),../../../share/mgis/cmakewith the default layout), so that the installation stays relocatable. Only new files are installed:<package>_DIR=<prefix>/share/mgis/cmakestill works, and the C and Fortran packages still find the core package next to them (HINTS ${CMAKE_CURRENT_LIST_DIR}). Not taken: moving the package files tolib*/cmake/<package>with forwarding files inshare/mgis/cmake(changes the layout seen by packagers and the hints between the packages); forwarding files inshare/cmake/<package>(architecture-independent place for files naming libraries); oneshare/MFrontGenericInterface/cmakedirectory (never searched for the-cand-fortranpackages).Limits: on Debian and Ubuntu,
CMakedoes not searchlib64, so an installation built withLIB_SUFFIX=64is not found through its prefix there (the defaultliblayout is); with two installations mixed,CMAKE_PREFIX_PATHis searched before the hints, so the C package found with_DIRin one installation may load its core package from another one listed inCMAKE_PREFIX_PATH, as it could already through a cachedMFrontGenericInterface_DIR.No test is added: no test uses the installed packages; the fix is checked with an external project (below).
Tested locally (Ubuntu 24.04, g++ 13.3, gfortran 13.3, CMake 3.28, TFEL master), with a small C++/C/Fortran project configured in an empty environment, loading
Gurson:CMAKE_PREFIX_PATH=<install>and<Package>_ROOTfail for the three packages;_DIR=<install>/share/mgis/cmakeworks.CMAKE_PREFIX_PATHalone (and_ROOT) finds the core,-cand-fortranpackages, separately and together;find_package(... 3.1)is accepted and 3.0 refused; the programs build and run; the former_DIRusage is unchanged.CMAKE_PREFIX_PATH,_ROOTand_DIR; no package file names the original prefix.MGIS_APPEND_SUFFIX=ON,MGIS_SUFFIX=3.1-dev,LIB_SUFFIX=64: real files inshare/mgis-3.1-dev/cmake, forwarding files inlib64/cmake/<package>-3.1-dev; the three packages are found whenlib64is searched.make check: 89/89 tests pass.References
find_package, "Config Mode Search Procedure" (https://cmake.org/cmake/help/latest/command/find_package.html): the directories searched under a prefix include<prefix>/(lib/<arch>|lib*|share)/cmake/<name>*/.