add easyblock for Score-P

[boegel]

This depends on easybuilders/easybuild-framework#754

[boegel]

@berndmohr: I implemented an easyblock for Score-P in this PR, to clean up the Score-P easyconfig in easybuilders/easybuild-easyconfigs#505, and to handle the lib/lib64 business that is required for the binutils and PAPI dependencies of Score-P (using the functionality added in easybuilders/easybuild-framework#754).

Any comments/remarks? This works fine on my end, but maybe you could give it a spin too using the new Score-P easyconfig from easybuilders/easybuild-easyconfigs#505? Let me know if you need help with that, since the PR this requires are not merged in yet...

[berndmohr]

@boegel: I do NOT like the direction this is taking. My team spent months to make the GNU autotools working for HPC setups (Fortran, compilers other GNu and Intel, etc etc) -- it is a perfect clean (GNU) configure/make/make install setup. It does not have any specific stuff in it, just the usual --with-something=XXX options which all other packages have too. So if this cannot be handled by the generic ConfigureMake EasyBlock, there is something wrong with the generic ConfigureMake EasyBlock!

It also would mean that I have to do this every time a package needs to specify something /lib/lib64 like in configuration options, I have to implement an easyblock, just to be able to call "get_software_libdir"?1?

I understand your wish to a quick solution to get this into 1.9 in time, but as I said the real fix would be the make the generic ConfigureMake EasyBlock able to handle situations like these. Cannot you implement
a special system variable @lib@ or whatever syntax you prefer which the generic ConfigureMake EasyBlock
replaces by the output of "get_software_libdir" when someone is using it in easyconfig variables?

[boegel]

@berndmohr: Please don't take this easyblock as an insult to Score-P. The main reason I implemented it is because several things have to be kept in sync in the easyconfig file:

• the --with-nocross-compiler-suite and --with-mpi configure options have to be aligned with the used toolchain
• the --with-X configure options for the dependencies have to be kept in sync with the list of dependencies

It's true that the lib vs lib64 issue that needs to be dealt with for --with-libbfd and --with-papi-lib is what pushed me over the edge, since handling that is only possible with get_software_libdir.

Supporting the get_software_libdir functionality directly in easyconfig files is certainly possible, and we will consider adding it at some point, but it's going to be less obvious than it may seem at first sight. If you look at the get_software_libdir call that we use to provide the correct libX subdir to --with-libbfd, you would need something like this in :

# set binutils library subdir that contains libbfd.a, there should be only one (hence the True)
configopts = "--with-libbfd=LIB_PATH('binutils', True, 'libbfd.a')"

If/when we support this, EasyBuild will replace the LIB_PATH('binutils', True, 'libbfd.a') part with a call to get_software_libdir (and get_software_root). Note that this is different than provided constants like SOURCELOWER_TAR_GZ since this is a function call, and I really feel we're stepping outside of the easyconfigs realm at that point...

So, to summarize: this easyblock makes writing easyconfig files for Score-P a lot more simple. You simply specify a toolchain and a list of dependencies, and EasyBuild will do the rest.

People who want to build Score-P with EasyBuild don't have to worry that you need to use --with-libbfd together with a binutils dependency, and that the autodetection for the PAPI dependency doesn't work because of the non-standard installation prefix that was used for PAPI (most likely because $PATH is not involved here). Also, they can easily change the toolchain for whatever reason, and eb will adjust the compiler and MPI configure options accordingly (or will tell you if it doesn't know how).
Without this, people who are not very familiar with the tool or with building software in general would easily misalign the --with-X configure options with the other specs, and thus run into problems.

I feel this is still relevant in the wake of easyconfig format 2.x, since it will still make the Score-P easyconfig file a lot less verbose (no explicit --with-X configure options, no 'exceptions' based on compiler/MPI, etc.).

[berndmohr]

@boegel: I never saw tbis as an insult for Score-P; I am just thinking that fat flexible easyconfigs are the way to go; leaving easyblocks to generic stuff and really nasty special stuff ;-) because in the long run easyconfigs are easier to contribute and maintain for a larger community, as writing easyblocks requires to be an easybuild expert (developer).

[fgeorgatos]

IMHO, people become easyblock-averse for two possible reasons:

• the fact that the effort is split across two repositories (with the different history, commit IDs etc) makes people consider as "too special" to deal with on daily basis; to me, this is an issue as regards not have a single commit ID, which functions as a transaction, when we update a given easyconfig/easyblock pair
• some easyblocks are exhaustively written (eg. not taking advantage of the skipsteps facility which is there for some time or, have the sanity checks hard-coded which most of the time are handled fine in easyconfigs); these effects make the easyblocks to appear more complicated than they really are.

From my point of view, each time I have to replace 1 line of easyconfig with X lines in easyblock, without getting extra functionality, I get suspicious if I do the task right; but you may have other takes...

[berndmohr]

=> intel2 very likely

intel: Intel MPI V1.X
intel2: Intel MPI V2.x or later
intelpoe: IBM POE MPI library for Intel platforms

[boegel]

I'm not sure what you mean by Intel MPI v1.x vs v2.x (but Intel is probably to blame here, not you ;-)).

How do I figure out whether the impi/4.1.0.027 module I have is v1.x or v2.x?

Can you point me to some documentation w.r.t. --with-mpi?

[fgeorgatos]

visually reviewed this easyblock;
no further comments other than the existing ones about code factorization etc;

remember the intel -> intel2 needed transition

[berndmohr]

impi/4.1.0.027 is version 4.X so it is "v2.x or later" so it is "intel2" ;-)

so impi/2..., impi/3...., should be all mapped to intel2
impi/1.... should be intel (if you care about really old versions)
Bernd

[boegel]

Score-P easyblock was cleaned up to also support other software packages, e.g. Scalasca v2.x, Cube 4.x, OTF2, LWM2

see easybuilders/easybuild-easyconfigs#505 for the related discussion

Thanks @berndmohr and @fgeorgatos for the feedback on this!