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