On Jul 8, 2011, at 6:34 PM, Dmitry Karpeev wrote:
When you say "Portability to Windows", do you mean "native Windows, without Cygwin"?
Yes, cll does this and I submit this is actually not difficult (some other requirements may be :-(
I agree that cmake is less than cool.
These are good points. I've added them to the master list in cll.py Now that we've started a list it would be a good idea to start adding thoughts on how each requirement could be met in a clean way. Barry
Suppose there is a package we need already installed on the system (e.g., hdf5 installed in <hdf5_dir>), which depends on another package we need, which is also already installed on the system (e.g., openmpi_dir, installed in <openmpi_dir>). The user requests --with-hdf5-dir=<hdf5_dir> --download-mpich. Is this dangerous? Can/should we be able to detect this?
On the system where I encountered this (Ubuntu), there is a package management system (apt-get) that contains the necessary information, but I think it would be prohibitively complex to make PETSc configure compatible with all package management systems so we can parse their package databases.
As a related matter, there is a sometimes unclear distinction between a package (e.g., mpich or openmpi) and an abstract "capability" (mpi), which can be satisfied by multiple packages (openmpi, mpich). We have both: --with-mpi-dir=<mpi_dir> (capability), --download-mpich=1 (package). This is, of course, due to the fact that the "capability" has a standard interface (the MPI standard), that multiple packages can satisfy. If FFT had a similar standardized interface we could potentially have the same ambiguity with fft and fftw. BLAS-LAPACK may be another such example.
Dmitry.
On Fri, Jul 8, 2011 at 4:48 PM, Barry Smith <[email protected]> wrote:
I am revisiting the idea of a new configuration/compile system for PETSc (with the prototype cll: ssh://[email protected]//hg/petsc/cll) and am currently trying to see if we can come up with a list of requirements that satisfies all our needs and everyone's ambitions. I have added a preliminary list at the top of the cll.py file in that repository and also posted here.
Requirements: X 1) Portability to Windows, Cygwin, Unix (all versions) 2) Compatible with GUI development systems (Xcode, Eclipse, Emacs, ...) 3) Able to run parallel configures and builds (on shared memory system enough?) 4) Able to work with batch systems 5) Able to handle dependencies between packages (given dependencies between packages builds everything in the correct order) 6) Able to utilize clang and similar systems 7) Works seamlessly with GNU autoconf and Cmake packages (that is will build these packages automatically) 8) Can download and install packages by given URL 9) Easy to add configurations for packages such as SuperLU, etc that have no decent configuration x 10) Can test for available functionalities (include files, etc) X 11) Easy to add new types of compilers, new tests 12) Does dependency analysis and rebuilds only what needs to be rebuilt 13) Able to manage test suites 14) Compatible with and able to use revision control systems 15) Completely command-line controlled but also with a GUI frontend that gives one full control as well 16) Able to build for bizarre-assed systems like the iPAD and GPUs.
X - does, x - does some
I looked at cmake recently and was not pleased with what I saw.
Any comments, thoughts, complaints and volunteers early solicited.
Barry