When you say "Portability to Windows", do you mean "native Windows, without Cygwin"? I agree that cmake is less than cool.
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 <bsmith at mcs.anl.gov> wrote: > > ? I am revisiting the idea of a new configuration/compile system for PETSc > (with the prototype cll: ?ssh://petsc at petsc.cs.iit.edu//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 > >
