[Users] WaveDemo question

[Erik Schnetter]

On Mon, May 28, 2012 at 3:21 PM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:
>
> On 28 May 2012, at 21:13, Erik Schnetter wrote:
>
>> We should really brush up our autoconf. We should remove all the fancy
>> stuff, and try to use cc/c++/f90 (or mpicc/mpic++/mpif90) for
>> building, using -O and -g as optimisation/debug options.
>>
>> The remaining complexity would be to autodetect how to build C99 code
>> (instead of C90 code), and how to link against the Fortran run-time
>> library. We should be able to automate this.
>>
>> This way, the option lists may improve performance, but people would
>> have a fighting chance to build out of the box. This probably wouldn't
>> help on all the crazy systems, but would simplify things for people's
>> laptops and workstations.
>>
>> We probably would also need to detect various kinds of configuration
>> problems, such as mis-installed compilers or MPI libraries.
>
> Yes, this is something I've been thinking about in the last few days.  I would like Cactus to be able to automatically configure itself on the most common platforms.  The "magic" is all in the known_architectures file, correct?  This seems to be a monolithic file which contains all the compiler detection, and is then duplicated for each architecture.  Would it make sense to modularise this?  We have pulled the library configuration out of Cactus itself into thorns.  Would it be possible to provide thorns for compilers as well, rather than have this knowledge as part of the flesh?  The build process might prohibit this, since configuration happens before the thorn scripts are run, and we need a compiler then.  As an alternative, maybe the known_architectures scripts could be split up into smaller parts (e.g. sub-script for each compiler etc).
>
> In a related note, it would be good if the simfactory optionlists could be simplified.  They should really just be there to specify library locations that cannot be auto-detected, and compiler flags for exceptional cases.  At the moment they are several screens long, and very intimidating.

Most of the truly architecture related stuff lives in Simfactory these
days, and could go away from the flesh, or could be reduced to a small
amount of code handling exceptions (e.g. "Cray requires MPI"). What
remains is mostly compiler specific, and not architecture specific,
and could be simplified as well. There is not much point in trying to
find elaborate sets of optimisation/debugging options for each
compiler version; -O and -g should be good enough (or maybe -O2).

I believe we could use regular autoconf tools to handle this. (We
would have to write a set of Fortran macros, because Fortran is not
well supported by autoconf.) Autoconf is easier to write than correct,
portable shell scripts. The advantage of autoconf is that one doesn't
have to parse the output of compilers; instead, one simply tries
whether something works, and after trying all variants that one knows,
one has either found something that works, or there is a problem that
can be reported right away.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/