[Top][All Lists]

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

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

From: Axel Arnold
Subject: Re: [ESPResSo-devel] Proposal: Overhaul of the build system
Date: Mon, 30 Mar 2009 10:18:37 +0200
User-agent: KMail/1.7.1

Am Donnerstag 26 März 2009 08:55 schrieb Olaf Lenz:
> 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"

That should be LIBS="-lmpi", and we should support changing both LIBS and 
LDFLAGS for libs and paths, respectively. LDFLAGS come before the object 
files and libs, and LIBS after the object files. That is important when using 
static libraries.

Otherwise, I am fine with the proposed changes.


> 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.
> Olaf
> _______________________________________________
> ESPResSo-devel mailing list
> address@hidden

Dr. Axel Arnold 
Fraunhofer SCAI
Schloss Birlinghoven, 53754 Sankt Augustin, Germany
Tel: +49 2241 14 2575

reply via email to

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