[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ESPResSo-devel] Proposal: Overhaul of the build system

From: Olaf Lenz
Subject: [ESPResSo-devel] Proposal: Overhaul of the build system
Date: Thu, 26 Mar 2009 08:55:07 +0100
User-agent: Thunderbird (X11/20080914)

Hash: SHA1

Hi everybody!

When we have a look at the user requests that come over the mailing
list, it meets the eye that many of the problems that users meet are
connected to the build system. The build system so far is adapted to the
pecularities of the MPIP, but easily causes problems in other systems.
For more details on these problems, see at the end of this mailing.

I want to make a proposal on how to change the build system such that it
is easier to maintain and more flexible at the same time, so that it is
simpler to configure, compile and use ESPResSo in non-MPIP settings.
The only drawback should be, that in the specific case of the MPIP it
requires a tiny bit more work to configure.

If anybody has problems with any of these changes, please write an email
to the list!

The following things would change:

1. The MPI compiler is *not* automatically detected anymore. Instead,
the user has to specify the required compiler when calling configure:

        configure CC="mpicc"

In the most cases, this will be enough. In some cases, it might be
necessary to specify required additional libraries instead:

        configure LDFLAGS="-lmpi"

2. The user can provide, how an MPI executable can be executed. By
default, the system will assume that an MPI executable can be run via
"mpiexec", which is defined by the MPI 2.1 standard and will work in
most standard settings, but if that doesn't work, he can provide his own
script to do that.

3. So far, when you compile ESPResSo in the source directory, it will
automatically create an "obj-xxx" directory based on the type of the
machine that configure is run and compile and run ESPresSo in that
directory.  In the ideal case, this should allow to compile different
ESPResSo executables for different platforms from the same source code,
when the source directory is available on different platforms.
This approach causes a number of problems (see below), and is mostly
obsolete since it is anyway easily possible to use a user-provided build
directory that is completely independent of the source directory.
Therefore, I would propose to completely remove that functionality.

Problems connected to the old MPI detection:
* When several MPI implementations are installed, it might easily happen
that the MPI compiler and mpirun from a different implementation are used.
* Newer MPI implementations (e.g. OpenMPI), or specific vendor
implementations (e.g. SGI Altix) are not readily detected, and it is
hard to teach the build system to crrectly handle these.
* Detecting the compiler while running configure causes some problems
with the GNU Autotools build system, which can lead to very strange
effects. For example, when using the xlc compiler of AIX, configure can
actually destroy the source code.
* On many HPC computers with a queuing system, it is not possible to run
an MPI executable easily, which can cause problems at configure time.

Problems connected to the automatic build directory creation:
* Users don't easily find the file "config.log" that should be included
in bug reports.
* The flexibility given by providing different "myconfig.h" header files
for different executables is gone when automatic obj-directories are used.
* The approach only works, when different platforms are actually
recognized as such. ESPResSo only recognizes platforms based on the
operating system and CPU type. When e.g. two Linux clusters with very
different Linux vcersions are used, they would still be compiled in the
same obj directory, which might easily lead to confusion.
* The approach does not go well with the GNU autotools system and has
only been superimposed onto the system.

Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]