[Users] Meeting Minutes

[Roland Haas]

Hello all,

>> I know this because I implemented this in Simfactory3, and I
>> definitively think this is the way to go. The current build recipes
>> use Clang (not gcc, and not the system's "standard" compiler) for
>> building. I did this because I was interested in C++11, and most
>> system compilers (Intel, PGI, older versions of GCC, current Nvidia)
>> don't support this. However, in the interest of backward compatibility
>> we should probably also provide build recipes for (say) an older
>> version of GCC that is supported by all compilers.
I will have to checkout and have a look at simfactory 3, so this may not
be the best advised course of action ever devised. However: generally I
would be happier if I had not to rely on simfactory (or any other
complex tool) to build the external libraries. I tend to prefer my tools
to do one thing and to that well. Simfactory (2) has become quite larger
trying to do many things. I fear that building the external libraries
such that they are compatible with the Cactus build (ie use the same
OPENMP settings, debug and optimization settings) may pull in a lot of
knowledge about the Cactus internal build system into simfactory which
will make it complicated. I can understand Erik's desire to be able to
build the ExternalLibraries independent of Cactus (for other projects)
using the understanding of what it takes to build them gained while
setting up the ExternalLibraries.

Also, not everyone is using simfactory. It may be possible to convince
people to use it to build external libraries but I do not think that one
can (nor should) try and force people to use simfactory to build Cactus
and to submit jobs using it.

I am actually mostly happy with the current external libraries. My only
desire would be for a collection of shell routines to be sourced to
handle common tasks. This is somewhat similar to autoconf (ok everything
there is eventually inlined into configure but at least on the m4 level
there are libraries of functions) or the debian build system (which does
source libraries of shell functions).

Basically I would suspect that a single mostly linear script is much
easier to understand for newcomers than a system that uses fragments of
scripts and a configuration file to stitch the fragments (and system
supplied code) together.

I also agree that the later is quite likely "nicer" and better suited
for large projects but and unsure if the dozen-or-so ExternalLibraries
(each of which has its own quirks) qualify.

With respect to the non-standard options used to build Cactus: are those
not also needed for the ExternalLibraries (if only to properly link with
Cactus)?

Please note that I have not problem (at all) if simfactory 3 is used
*by* Cactus as a library (with extra code added to get eg the compile
options from the Cactus build system), my only concerns is using it to
drive the Cactus build process (and the ExternalLibraries) thus having
to know what Cactus will do.

Yours,
Roland

-- 
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://keys.gnupg.net.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 242 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20140325/c8bdeb58/attachment.bin