Build aspect.debug and/or aspect.release, then link to it.

geodynamics / aspect

A parallel, extensible finite element code to simulate convection in both 2D and 3D models.

https://aspect.geodynamics.org/

Other

217 stars 232 forks source link

Build aspect.debug and/or aspect.release, then link to it. #5836

Closed bangerth closed 2 weeks ago

bangerth commented 1 month ago

This continues my quest to unclutter the cmake scripts. In particular, I'm getting rid of the TARGETS and TARGET variables, which are particularly cumbersome because plenty of cmake commands have TARGET keywords (e.g., set_property(TARGET ${TARGET_EXE_DEBUG} PROPERTY OUTPUT_NAME aspect.debug)).

The end result is that we build executables aspect.debug and/or aspect.release (depending on CMAKE_BUILD_TYPE) and in the end create a symlink from one or the other to aspect.

bangerth commented 1 month ago

Oh dear, it's cmake/AspectConfig.cmake.in again...

tjhei commented 1 month ago

not quite. :smile:

bangerth commented 4 weeks ago

It seems to work in its last iteration.

tjhei commented 4 weeks ago

I am not convinced that installation and plugins still work the same way. Give us some time to test this branch locally.

bangerth commented 3 weeks ago

OK. Feedback welcome!

gassmoeller commented 3 weeks ago

I have tried this a bit locally, here are some observations:

the symlink aspect is not installed during make install (the binaries are). this leads to broken symlinks if plugins are linked against the installed version of ASPECT
the libraries of Worldbuilder are installed into the bin directory during make install, even though they are statically linked into the binaries, is this what we want? (this may be behavior controlled by the world builder cmakelists)
when I build a plugin with ASPECT in DebugRelease mode I get plugin libraries named *.debug.so and *.release.release.so. somewhere it is pickung up the release twice.

bangerth commented 2 weeks ago

OK, I think I've got this fixed:

The symlink now also exists in the install directory.
The installation of the worldbuilder shared libs is something that results from just using add_library in contrib/world_builder, which creates a library and all libraries are automatically installed. I do not know if that can be suppressed. (I am surprised that they are installed in .../bin, rather than .../lib, but that happens in contrib/world_builder/CMakeLists.txt, a file I am not proposing to touch here :-) )
I've removed the duplicate .release part. This results in libXXX.debug.so and libXXX.release.so.

This seems to all work for me now. Can you give it another try?