[Dune] Dune and CMake

[Jö Fahlke]

Am Mon, 15. Feb 2010, 18:58:16 +0100 schrieb Oliver Sander:
> I have been wanting to ask the following concerning cmake
> for quite a while.  My question goes both the people in Stuttgart
> and to the maintainers of the Dune build system.  Is it possible
> _without being very invasive_, to extend the duneproject script
> to create on demand either an AutoTools build system or a
> cmake build system in the new module?  I know this would involve
> modifying dunecontrol so as to also build Dune modules
> with a cmake build system.  To make things easier one could
> say that cmake modules cannot be depended upon.
> I think it would be interesting to have such a mechanism
> (again, I stress: if it is not too invasive), because it would give
> the users more choice and allow us to try out cmake and
> evaluate it.

OK, I guess the "maintainers of the buildsystem" really don't know a lot about
cmake.  So that makes your question difficult to answer.  Here is the
guesswork that I can give you:

* dunecontrol: We probably have to change the autogen and the configure
  stuff.

  - autogen: cmake may be able to do that itself, so we may get away with "if
    cmake do nothing", but of course someone has to implement reading the
    dune.module files and the ordering of dependencies in cmake.  It is
    probably easier to let dune-autogen write some file for cmake, since it
    already has all the necessary data.

  - configure: cmake most certainly takes different arguments than autconfs
    configure scripts.  This would mean another variable CMAKE_OPTS in
    dunecontrol.opts, which the user has to keep in sync with CONFIGURE_OPTS.

* duneproject: Just writing a different set of template files should not be
  too difficult.  The difficult part is the actual contents of these template
  files.  The problem here is that every module can have it's own set of
  configure checks run by the modules that depend on it.  These configure
  checks can and do very sophisticated things: for instance putting "#define
  HAVE_ALBERTA ENABLE_ALBERTA" in config.h and then giving the ENABLE_ALBERTA
  define in the CPPFLAGS (of course, there are probably much worse examples).
  Essentially, you probably need half of a cmake build system for every
  autoconf using module you want to depend upon.  And you have to keep that
  buildsystem in sync with the autotools buildsystem.  Which we cannot in the
  users modules, so we would have to do it in the core modules.  Which would
  amount to having to buildsystems.

On the other hand, given a particular module with a limited set of
dependencies, lets say the core modules without any external dependencies, it
should be possible to create a custom cmake buildsystem for it.  (Note that
possible does not mean easy).  Also, that ensures that whoever created that
buildsystem has at least some basic knowledge about it and is able keep it in
sync with Dunes buildsystem.

Jö.

-- 
Gute Nacht Deutschland.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20100215/64ec0ae7/attachment.sig>