[Users] Meeting Minutes

Tue Mar 25 11:01:47 CDT 2014

On Mar 25, 2014, at 11:37 , Roland Haas <rhaas at tapir.caltech.edu> wrote:

> 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.

No, there is nothing Cactus specific in Simfactory3's build system for external libraries.

I will be happy to show you how external libraries are built. In principle, it's just "download, unzip, configure, make, make test, make install, test", but in practice almost all packages need quite a bit more work.

You don't need to use Simfactory for anything else. This mechanism just installs external libraries, that's all it does.

However, there are a few interesting bits that Simfactory provides that are quite useful when building external libraries. You could specify these things manually when you build, or you could devise your own database holding these settings, if you want:
- the directory where to install things
- how the "make" command is called
- whether (and which) modules to load before building

> 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).

Shell routines are fine. However, I prefer Python, and have thus written a Python module for these common tasks.

> 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.

You would be surprised.

Let's talk about downloading only, ignoring patching/configuring/building/testing/installing etc. for the moment.

What command do you use to download? Let's assume you go for "wget", and let's assume it is available everywhere.

Now, you probably don't want to re-download a tarball that is already there. You can use if statements and tests for that, but luckily, wget has an option for this, "-c", so you use that.

Next you notice that wget doesn't always download tarballs when the url starts with https. Many system administrators can't seem to get their certificates up to date. So, you need to add --no-check-certificate. (Plus, you are not really interested in a secure connection to the web server, you really want end-to-end security, which only a GPG signature or checking md5sums will get you, to https doesn't help much anyway.)

Next you notice that Sourceforge (sic!) sometimes goes into endless redirection loops when the wget "-c" option is used. So you need to call wget twice: First with "-c"; then, if that fails, retry without "-c". That's inconvenient, but what can you do.

Next you find that wget chooses a bad file name when downloading *.zip files. So you need to use the "-O" option. That means you either need to specify the file name twice (as part of the url, and as argument to "-O"), or you need to use a function that automatically extracts the last part of the url. (Python provides such a function.)

Then, of course, there is the fact that some libraries (e.g. GCC) require multiple downloads. GCC requires six (!) different tarballs. So, open-coding all the wget magic gets cumbersome -- you want a list of urls, and a loop around the wget magic, or you need to define a shell function to wrap wget.

Now we can download tarballs. (Ian's Boost script that he posted earlier ago isn't even halfway there yet.) Next comes checking md5sums, unzipping, etc... None of these are as trivial as they should be. Things always break, and having something that "just works" requires quite a bit of non-trivial logic. A linear bash script isn't the way to go... Note that I always start out with linear bash scripts, and then always get cornered into writing something more complex.

> 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.

Give it a try. Pick an easy library (stay away from Boost, PETSc, HPX), and write a simple, linear script that works on all the systems that your group is using -- your local laptop and workstation, as well as the "usual" XSEDE and NERSC machines. (Leave out Crays and Blue Genes for now.) The script should download, unzip, configure, build, and install a library, and then run a simple test ensuring that the library has been installed fine, such as e.g. compiling and running a five-line C program that outputs the library's version number to stdout.

> 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)?

You don't need these. A standard install will work fine, if you make sure that some basic things match (e.g. libstdc++ version).

> 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.

It doesn't. I'm using Simfactory3 for non-Cactus projects as well. That works just fine. That's one of the reasons for Simfactory3. It just gives you some nice Python modules (sorry, no Bash scripts to pull in) to do simple tasks. Such as, "tell me what the make command is called on this system".

-erik

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

My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu/.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20140325/ee40414d/attachment.bin 