[Dune] [#1000] Evaluate build system migration from autotools to CMake

Dune flyspray at dune-project.org
Mon Jun 11 21:20:11 CEST 2012


THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1000 - Evaluate build system migration from autotools to CMake
User who did this - Sascha Zelzer (sascha)

----------
Hi!

The CMake system I published for building DUNE modules can also dynamically configure and build "external" DUNE modules. The CMake variable DUNE_MODULE_DIRS can be filled by the user with directory entries containing DUNE modules (very much like DUNE_CONTROL_PATH works). Only the list of DUNE Core modules for the bootstrapping process is static (a DUNE release is made up of a static list of core modules anyway).

I could also elaborate a little bit on the problems we had with integrating DUNE in our system: If we had used autotools for our build system, most of the issues would not have arisen of course. However, our software stack is required to run cross-platform in a native environment (no Cygwin et. al. on Windows) and to provide good IDE support - hence we use CMake. All of our software needs to be integrated with this system, because we rely on CTest as a unit testing and continuous integration system. For third-party libraries (like DUNE), we create simple CMake scripts to be able to build all dependencies automatically. This is easier for third-party libraries supporting CMake, but is usually not a big problem otherwise. For DUNE however, the efforts where much higher. Largely due to the amount of third-party libraries needed by other DUNE modules (this is of course not a fault of any DUNE build system) but also due to the fact that we needed to be able to write "DUNE modules" which
fit into our build system. Using autotools for a small portion of source code (the new DUNE module) in our repository and getting it to "work together" with other targets build in the same CMake project and integrating it nicely with the testing and integration system was just not feasible. It is also against our department policy... I do of course know that these problems are ours and not the ones of DUNE.

I also agree with Alf that CMake could probably lower the barrier for non-expert DUNE users.
----------

More information can be found at the following URL:
http://www.dune-project.org/flyspray/index.php?do=details&task_id=1000#comment3723

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.




More information about the Dune mailing list