CMake build

[dutkalex]

Hi!
I am working on a CFD software and we'd like to use t8code to do our AMR. For portability reasons (among others), I would like to be able to build everything from source in one go, in an automated fashion. Our build system is CMake-based, and I'd like to simply add t8code as a git submodule, insert an add_subdirectory( tpls/t8code ) in my CMakeLists.txt, and configure t8code automatically and on the fly, based on the project-wide configuration flags.

This is actually very difficult to achieve with the current build system of t8code, and I have started to prototype an alternative CMake-based build system for t8code which would be easier to work with. However, doing the reverse-engineering of the build sequence on my own is quite difficult and I could use some of your insights on how I could proceed. In particular, I am currently stuck as I don't know yet how to gracefully emulate the generation of the t8_config.h file by the configure script...

If I manage to get this to work properly as an alternative to the current build system, would you guys be willing to upstream this?

[holke]

Hello @dutkalex and welcome to the t8code community.
We apprechiate your contribution.
Having a working Cmake would indeed benefit all t8code users and it is on our midterm TODO list.

Have you already checked out p4est and sc? As i understand they have a working CMake now and they use a very similar build system setup as t8code.

Also, you may want to talk to @CsatiZoltan (edit: seeing now that you are from CERFACS as well, so you might already be in contact)

[holke]

@dutkalex could you write me a short mail please so that we can get in touch?
johannes.holke at dlr.de

[CsatiZoltan]

This issue is related to #786, but is more general. In that discussion thread, I showed an example how to integrate t8code into a CMake project. It works well, but @dutkalex wants a tighter integration: create a CMake build for t8code itself. As t8code is on its way to modernize for C++, it would be useful in my opinion to provide a CMake build too.

[dutkalex]

I have started to implement this feature in #929. Suggestions, reviews and contributions are of course welcome and appreciated

[cburstedde]

I have started to implement this feature in #929. Suggestions, reviews and contributions are of course be welcome

We have indeed had lots of help on the CMake builds of p4est and sc by @scivision and @pkestene. These updates are supposed to be in addition to the autoconf build, not exclusive, and produce the same configurations. In particular, both processes generate equivalent sc_config.h and p4est_config.h files. Please check out the cmake subdirectory and CMakeLists of the p4est and sc sources. Ideally you can reuse some of it. The autoconf system allows to build p4est and sc in the same build, or to reference them from a make installed location. Both is supposed to be possible with CMake, too, and lately our CMake understands git submodules. The system is far from complete though. There is cburstedde/p4est#103, which is a bit outdated. Specifically, there seems to be no equivalent for make dist, make distcheck, basically all the goodies that are inherited from automake. The cpack tarball also has a different structure to the .tar.gz from automake, which would need to be fixed eventually. We'll be happy to coordinate reuse of cmake code as much as we can! If you find anything that should be improved on the p4est and sc side, please let us know. I'd find it useful to have the three codes' builds be as close and non-redundant as possible. Please consider the latest develop branches of p4est and libsc.

[dutkalex]

We'll be happy to coordinate reuse of cmake code as much as we can! If you
find anything that should be improved on the p4est and sc side, please let
us know. I'd find it useful to have the three codes' builds be as close and
non-redundant as possible.

Yes @cburstedde , that would be great indeed! As a matter of fact, I did notice things that could be improved in both sc and p4est's CMake build systems, but I am focused on finishing #929 for now.

Please consider the latest develop branches of p4est and libsc.

I don't know if t8code uses the most recent versions of sc and p4est, and maybe some of these issues have been solved already, but I'd be happy to help with your CMake build systems once @jmark and I are done with t8code's.

[cburstedde]

> We'll be happy to coordinate reuse of cmake code as much as we can! If you > find anything that should be improved on the p4est and sc side, please let > us know. I'd find it useful to have the three codes' builds be as close and > non-redundant as possible. Yes, that would be great indeed! As a matter of fact, I did notice things that could be improved in both sc and p4est's CMake build systems, but I am focused on finishing #929 and getting it integrated.

That sounds great!

> Please consider the latest develop branches of p4est and libsc. I don't know if t8code uses the most recent versions of sc and p4est, and maybe some of these issues have been solved already, but I'd be happy to help with your CMake build system once @jmark and I are done with t8code's own CMake build system.

It will probably best to use the latest p4est and libsc develop branches and go from there. Then it will be easier to give back your changes to them.

[cburstedde]

> I don't know if t8code uses the most recent versions of sc and p4est, and maybe some of these issues have been solved already, but I'd be happy to help with your CMake build system once @jmark and I are done with t8code's own CMake build system. It will probably best to use the latest p4est and libsc develop branches and go from there. Then it will be easier to give back your changes to them.

There is one incompatible change wrt. the @_EDEPS@ variables in src/Makefile.am. Happy to help get these updates integrated.

[dutkalex]

Closing this issue as #929 is now integrated, and new CMake related features will be tracked in #954