[petsc-dev] CMake proof of concept

[Barry Smith]

   Likely we need a subdirectory somewhere to put all the make makers. I would like a subdirectory of bin/maint; likely Matt wants a subdirectory of config

   Currently config is almost all just config stuff, but Matt put his builder.py that makes in there. I don't object to having the make stuff in config except then it shouldn't be called config anymore. Perhaps there should be a "make" directory at the top level? But then does the conf stuff go, into that make directory?

    config/                             all configure stuff
                PETSc
                BuildSystem
    make (or build?)/          all make stuff
               conf                       need better name; what is currently in conf   - this is class makestuff
               cmake                   for Jed's C make
               Matt                       for Matt's builder.py
               other                     for iphonebuilder.py etc
               scripts or bin       for allfortranstubs.py and similar beasts



    Barry

On May 31, 2010, at 10:23 AM, Jed Brown wrote:

> In this latest buzz about build systems and IDE integration, I added a
> CMake build to PETSc.  It is entirely contained in bin/maint/cmakegen.py
> and bin/maint/cmakeboot.py and supports multiple PETSC_ARCH, Fortran,
> C++ (currently only with-c-support), complex/precision/etc, with and
> without single-library, static or shared, and coexists with the existing
> build system.  The primary motivation for this was (a) dependency
> analysis, (b) parallel builds, (c) IDE integration, (d) more
> sophisticated test summaries (later, maybe,
> cf. http://public.kitware.com/dashboard.php).
> 
> Usage:
> After generating ftn-auto if necessary, run
> 
>  bin/maint/cmakegen.py
> 
> which creates a PETSC_ARCH-agnostic $PETSC_DIR/CMakeLists.txt which
> describes the build in terms of the variables that might be set by each
> PETSC_ARCH (I put it all in one file so as to be as unintrusive as
> possible).  This might need to be rerun after pulling new sources, but
> it is fast (<1 second).
> 
> Then, after running configure for your given PETSC_ARCH, run
> 
>  bin/maint/cmakeboot.py
> 
> which initializes CMake's build in that directory.  This normally only
> needs to be run once, CMake's cache and dependencies will be updated as
> necessary (e.g. a source file includes different headers or
> CMakeLists.txt changes after rerunning cmakegen.py).  This script
> accepts arguments to be passed on to CMake, such as
> 
>  -G'Eclipse CDT4 - Unix Makefiles'
> 
> which creates an Eclipse project file with an accompanying
> Makefile-based build.  I've tested import with Eclipse, KDevelop, and Qt
> Creator; a variety of other IDEs are supported (including XCode and
> Visual Studio) but I don't use those platforms so can't test them).
> Note that most IDEs have a way to manage multiple "build
> configurations", which correspond to multiple values of PETSC_ARCH.
> Usually you point them to $PETSC_DIR/CMakeLists.txt and then specify a
> build directory which would be $PETSC_DIR/$PETSC_ARCH for whichever
> configurations you want.
> 
> Both of these steps should be very fast and idempotent.  At this point,
> the values of PETSC_DIR and PETSC_ARCH (in your environment) are no
> longer of any consequence, everything is determined by the location of
> the build directory.  Managing multiple builds is easy, for example,
> just run (assuming a Makefile based build)
> 
>  $ make -C arch1 -j3 &  make -C arch2 -j5 &
> 
> to update the libraries for multiple configurations at once with several
> processes each.  The object files reside in $PETSC_ARCH/CMakeFiles so
> their presence doesn't interfere with other builds and refreshing is
> fast (only rebuild when necessary, do-nothing rebuild takes less than 1
> second without single-library, a slightly more with single-library).
> 
> I currently don't do anything with examples, I suggest building them as
> usual with PETSc's current system until/unless they are added to this.
> I haven't provided a public PETScConfig.cmake and haven't addressed
> installation.
> 
> 
> I declared a CMake compatibility version of 2.6 because that's the
> oldest I've tested.  The scripts cmakegen.py and cmakeboot.py require
> Python 2.5 because I wanted newer language features.  It could easily be
> ported to older pythons if that became important, but the whole thing is
> just a proof of concept at this stage.  These versions are not hard to
> come by and I would imagine that everyone's development machine is
> relatively current.
> 
> Let me know about any issues.
> 
> Jed