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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
