Skip to content

restructuring and upgrades to cmake-infrastructure

Nick R. Papior requested to merge npapior/siesta:342-cmake-upgrades into master

restructuring and upgrades to cmake-infrastructure

This is a somewhat big rewrite of many things internal to the cmake infrastructure:

Bumped minimal version to 3.20 which allows one to DEFER calls (post-pone a call until the end of the add_subdirectory step). (3.19 for DEFER, 3.20 for fixing #318 (closed))

Added:

  • SIESTA_TESTS
  • SIESTA_SHARED_LIBS
  • SIESTA_INSTALL The above is mainly for future-proofing the codebase against being inherited in a project.

After advice from Christian Le, (LecrisUT). One should generally define the exposed executables through the top-level CMakeLists.txt. I tried moving them up, but then the source compilations happen at the directory of definition. So I decided not to do it.

Added some more print-build-options at the end of the configure step. The shown options are mainly those that affect only siesta. I.e. units-convention, suffix names etc. It gives a better overview.

Added the CMAKE_MESSAGE_CONTEXT which can be quite handy.

Changed lots of explicit function names in debug messages to use CMAKE_CURRENT_FUNCTION (does not work in macro's for obvious reasons).

Enabled these flags:

  • SIESTA_LINKER_FLAGS_PRE
  • SIESTA_LINKER_FLAGS_POST
  • SIESTA_LINKER_FLAGS

these will be added to the siesta and libsiesta targets. (more will be added in a later commit). These flags are the reason we have to bump the cmake dependency version. The reason is that we now require a new way of adding libraries. (I am up for suggestions to streamline this). The way this works is by creating a wrapper for add_executable|library. This wrapper then defines the executable with all its arguments, and then immediately installs a

target_link_libraries( ${SIESTA_LINKER_FLAGS_PRE})

It then installs a deferred call when the directory is done parsing which calls:

target_link_libraries( ${SIESTA_LINKER_FLAGS_POST|})

We might consider doing the deferred call only when the PROJECT_SOURCE_DIR is done (can easily be done). Basically this wraps all of this:

add_executable(target ...) target_link_libraries(target SIESTA_LINKER_FLAG_PRE)

< add more link libraries >

target_link_libraries(target SIESTA_LINKER_FLAG_POST)

into:

siesta_add_executable(target ...)

< add more link libraries >

Whether or not this is the best way to do things, I don't know. We could also create other functions which installs the PRE and POST flags, but that would require 2 more function calls at determined positions.

Beautified the printbuildinfo scripts. when using different modes in the MESSAGE one needs to worry about the -- prefix for STATUS and above (i.e. NOTICE won't have these). For better formatting now everything is STATUS. Once 3.25 is in, one can bypass the mode flag and use a custom msg function which prints with NOTICE mode but only for DEBUG. Reduced the spacing a bit, and just generally made it look prettier.

The test-suite got changed input flags:

  • SIESTA_TESTS_MPI_MIN|MAX_NUMPROCS (follows MPI naming convention)
  • SIESTA_TESTS_MPI_NUMPROCS (actual used number of ranks, defaults to 4)
  • SIESTA_TESTS_VERIFY A function siesta_test_get_mpi has been added. It is currently not used, as I would like some feedback on it. The test functions were shortened to a great extend due to equivalent branches, the IS_SIMPLE option is now also removed since it got superseeded by the LABELS (see internal #344).

Changed the test names to be a bit shorter, and also changed the amount of printed information. Much of it I would regard as debug information.

Should we simply use prefix SIESTA_TEST_?

The SUFFIX handling in Siesta got a reduced output scope. It generally shouldn't require a big investigation, and hence it has reduced its verbosity.

Signed-off-by: Nick Papior nickpapior@gmail.com

Details

Please detail what this MR introduces

  • Describe in details what this MR does? (link to the issue by writing # here)
  • Does this MR change the behaviour of any fdf-flags? If so, ensure this is documented in the manual
  • If new fdf-flags are added, please add thorough descriptions to the manual
  • add a summary sentence in the ReleaseNotes.md file
  • if this breaks compatibility, add mentions to the Docs/compatibility.tex
  • backport to rel-5

Also needs to fix the last details of the SiestaSubroutine utils (which is currently commented out).

Why is it needed

Authors

Closes #318 (closed), #342 (closed), #344 (and possibly others)

Edited by Nick R. Papior

Merge request reports