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
