{perf}[gompi/2019a] Score-P 6.0 + Scalasca 2.5 + deps #6328

geimer · 2018-05-16T10:48:15Z

Minimal-toolchain versions (hierarchical MNS) for gompi/2018a.

boegel · 2018-05-17T11:18:38Z

easybuild/easyconfigs/o/OTF2/OTF2-2.1.1-GCCcore-6.4.0.eb

+    # Python bindings (optional)
+    ('Python', '2.7.14', '-bare'),
+    ('future', '0.16.0', '-Python-2.7.14-bare'),
+    ('Six', '1.11.0', '-Python-2.7.14-bare'),


@geimer By using a -bare Python here, you're effectively making this incompatible with anything that depends on a full Python, which is quite common... Isn't that a concern?

Maybe it makes sense to make the Python that gets built with GCCcore a trimmed down version of the one we have with a full toolchain, i.e. still include common dependencies like six, future, setuptools, pip, etc into it?

On second though, not using some versionsuffix for a Python built with GCCcore is probably going to create issues too, especially when EasyBuild is configured with --minimal-toolchains.
Yet, create a -base or -minimal variant that includes a bunch of extensions makes more sense? See also #5072

@boegel There doesn't seem to be any consensus how to deal with Python on the GCCcore level, cfr. the discussion I raised two or three weeks ago on the mailing list. I'm doing something here to make progress, but the Python stuff needs to be fixed first, and then I can adjust this PR accordingly. But I'm not the one who is going to take a lead on this, as there are too many dark corners I don't understand...

@boegel Thinking about it, things are even worse... To support both Python2 and Python3, I would need to build two different OTF2 installations (with different dependencies). But which one should I then use to build Score-P (which doesn't need Python at all)? Whichever choice I make may be wrong, as a user may need "the other Python" for his code...

Maybe I'll just ignore the Python bindings for now and leave them disabled...

Good point... Maybe you can consider building the Python bindings in a separate module, which can be loaded as needed?

Not sure our build system supports this right now. Is there any support in EB for building things twice into the same prefix but with different build dependencies (like with a list of configopts)? This may work too, but I would immediately admit that this is a rather strange feature request ;-)

Wait... This won't work either due to PYTHONPATH having to point to one or the other site-packages directory...

Talking to the OTF2 core devs, this currently seems to be the only option: building OTF2 twice into the same prefix with the different Python's as build dependencies, and then providing Python binding modules that simply depend on the common OTF2 installation and only set PYTHONPATH accordingly. But I don't think this is currently possible with EB...

Not in a clean way, no, but it relates closely to the way in which the ComputeCanada folks install Python packages, so we should come up with a clean way of doing that anyway...

@bartoldeman @mboisson Do you have your approach clearly documented somewhere? Maybe it's time to start implementing this...

What our approach boils down to:

Let the Python module set PYTHONPATH to a location with a file sitecustomize.py

this file has the following contents:

import sys import os import site # use prefixes from EBPYTHONPREFIXES, so they have lower priority than # virtualenv-installed packages if "EBPYTHONPREFIXES" in os.environ: postfix = os.path.join('lib', 'python'+sys.version[:3], 'site-packages') for prefix in os.environ["EBPYTHONPREFIXES"].split(os.pathsep): sitedir = os.path.join(prefix, postfix) if os.path.isdir(sitedir): site.addsitedir(sitedir)

modules that use Python set EBPYTHONPREFIXES. We now do it as follows:

modextrapaths = { 'EBPYTHONPREFIXES': [''], }

module have to load different python modules for builds. We now do this as follows:

prebuildopts = ['module load python/2.7 && ', 'module load python/3.5 && ', 'module load python/3.6 && ']

but that's a hack. It would be better to allow builddependencies to be a list of lists.
5. we have this for some modules that absolutely need python (for some it is optional):
modluafooter = """
depends_on("python")
"""
this basically will load the default python if none is loaded and otherwise keep whatever python module is already loaded.

Hope that helps.

boegel · 2018-05-17T11:19:19Z

easybuild/easyconfigs/s/Six/Six-1.11.0-GCCcore-6.4.0-Python-2.7.14-bare.eb

@@ -0,0 +1,34 @@
+easyblock = 'PythonPackage'
+
+name = 'Six'


Should be six, cfr. http://six.readthedocs.io/: The name, “six”, comes from the fact that 2*3 equals 6.

boegel · 2018-05-17T11:20:09Z

@geimer This PR is getting quite big, are all of these inter-dependent? Is it worth fleshing out the Python built with GCCcore in a separate PR?

different way

…gs into scorep_scalasca_update_hmns_mintc

boegel · 2019-05-09T09:20:22Z

@geimer How do we proceed with this? Bump to 2019a where we have Python and Qt5 built with GCCcore?

geimer · 2019-05-09T09:35:00Z

@boegel Yes, my idea is to use 2019a with Qt5 from #8201 and bump versions to the latest Score-P/Scalasca/Cube releases. I will start working on this once my Qt5 build has finished...

…gs into scorep_scalasca_update_hmns_mintc

geimer · 2019-05-10T12:22:47Z

@boegel As outlined yesterday, I've updated this PR to the latest tool versions for 2019a. Installations are fairly feature-complete, except for:

OTF2 can be built with Python bindings. I haven't included Python as a dependency yet, as I'm not quite sure how to use the multi_deps thing introduced recently. Any pointer?
Score-P's library wrapping feature is not enabled, as it requires LLVM + Clang libraries (built as one blob). The LLVM configs currently available are not sufficient, and Clang is of moduleclass compiler and thus conflicts with GCC. That is, it would require a redesign of how LLVM and Clang are provided in EasyBuild.
Other optional Score-P features such as OpenACC, OpenCL, and CUDA support have to be enabled on demand.

geimer · 2019-05-10T12:49:47Z

Hmm... Isn't the Travis test too strict here? IMO a "pure" bundle that only depends on other packages shouldn't be required to specify sanity_check_paths. One way to work around this would be to re- check things that have already been checked in the underlying packages, but this is (a) redundant and (b) error-prone. Any comments?

boegelbot · 2019-05-10T12:53:13Z

Travis test report: 2/2 runs failed - see https://travis-ci.org/easybuilders/easybuild-easyconfigs/builds/530716128

Only showing partial log for 1st failed test suite run 14970.1;
full log at https://travis-ci.org/easybuilders/easybuild-easyconfigs/jobs/530716129

...
FAIL: Specific checks only done for the (easyconfig) files that were changed in a pull request.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/easybuilders/easybuild-easyconfigs/test/easyconfigs/easyconfigs.py", line 505, in test_changed_files_pull_request
    self.check_sanity_check_paths(changed_ecs)
  File "/home/travis/build/easybuilders/easybuild-easyconfigs/test/easyconfigs/easyconfigs.py", line 450, in check_sanity_check_paths
    self.assertFalse(failing_checks, '\n'.join(failing_checks))
AssertionError: No custom sanity_check_paths found in Cube-20190321-GCCcore-8.2.0.eb

----------------------------------------------------------------------
Ran 11385 tests in 1266.558s

FAILED (failures=1)
ERROR: Not all tests were successful.

14970.2 - errored => https://travis-ci.org/easybuilders/easybuild-easyconfigs/jobs/530716130

*bleep, bloop, I'm just a bot (boegelbot v20180813.01)*Please talk to my owner @boegel if you notice you me acting stupid),or submit a pull request to https://github.com/boegel/boegelbot fix the problem.

boegel · 2019-05-15T08:48:22Z

@geimer You're absolutely right, we should whitelist easyconfigs that use Bundle (and don't have extensions listed), much like we whitelisted Toolchain in #8216 .

Are you up for looking into that yourself?
This should be helpful: c56010e

Note that it's a bit more involved than just checking for the use of Bundle, since we also have bundles of extensions (where having a custom sanity_check_paths is still very much desired).

boegel · 2019-05-15T08:53:20Z

easybuild/easyconfigs/c/Cube/Cube-20190321-GCCcore-8.2.0.eb

+dependencies = [
+    ('CubeWriter', '4.4.2'),
+    ('CubeLib', '4.4.3'),
+    ('CubeGUI', '4.4.3'),


@geimer Does it actually make sense to have these as separate installations?

If not, you could use the components support in Bundle to simply pack them together in a single installation prefix/module, much like we do with X11, see https://github.com/easybuilders/easybuild-easyconfigs/blob/master/easybuild/easyconfigs/x/X11/X11-20190311-GCCcore-8.2.0.eb

boegel · 2019-05-15T08:54:28Z

easybuild/easyconfigs/c/Cube/Cube-20190321-GCCcore-8.2.0.eb

+easyblock = 'Bundle'
+
+name = 'Cube'
+version = '20190321'


Maybe clarify how this was picked? Is it the release date of the most recent component included in this bundle?

Does it make sense to use the version of the "main" component instead (4.4.3), which is much closer to what people would expect when installing Cube?

There is no "main" component. The former Cube package has been split into three disjoint componts: CubeWriter, CubeLib, and CubeGUI. They now evolve somewhat independently and version numbers may diverge more over time. In this case, the three components have been released on the same date (chosen as version), but this doesn't have to be the case in the future. Dependent packages may require only some of them or in different use cases (dependency vs. builddependency, see the Score-P easyconfig), thus I would really prefer to keep them separate.

In principle, the Cube bundle isn't required at all -- I've just added it as a convenience for people who are used to the old Cube package. While we also provide a convenience bundle tarball including all components on our web page, its version is a simple count that has very little to do with the versions included (as the versions are allowed to diverge, it is hard to come up with a common version). Having said all this, I'm also OK with removing the bundle if you think it causes too much confusion. (This would also magically "fix" the failing Travis check 😉)

boegel · 2019-05-15T08:58:02Z

easybuild/easyconfigs/c/CubeGUI/CubeGUI-4.4.3-GCCcore-8.2.0.eb

+sanity_check_paths = {
+    'files': ['bin/cube', 'bin/cubegui-config',
+              ('lib/libcube4gui.a', 'lib64/libcube4gui.a'),
+              ('lib/libcube4gui.%s' % SHLIB_EXT, 'lib64/libcube4gui.%s' % SHLIB_EXT)],


@geimer You can drop the "lib or lib64" bit here, and just specify the paths using lib/.

Since EasyBuild v3.6.1, there's an automatic fallback to checking for lib64/x if lib/x was not found (and vice versa if lib64/x was specified), see easybuilders/easybuild-framework#2477.
It's enabled by default (and disabling it requires configuring EasyBuild with --disable-lib64-fallback-sanity-check`, which I doubt anyone does, allowing that was just a safety measure we put in place in case surprises popped up).

boegel · 2019-05-15T08:58:13Z

easybuild/easyconfigs/c/CubeLib/CubeLib-4.4.3-GCCcore-8.2.0.eb

+sanity_check_paths = {
+    'files': ['bin/cubelib-config',
+              ('lib/libcube4.a', 'lib64/libcube4.a'),
+              ('lib/libcube4.%s' % SHLIB_EXT, 'lib64/libcube4.%s' % SHLIB_EXT)],


only lib/ is fine

boegel · 2019-05-15T08:58:22Z

easybuild/easyconfigs/c/CubeWriter/CubeWriter-4.4.2-GCCcore-8.2.0.eb

+sanity_check_paths = {
+    'files': ['bin/cubew-config',
+              ('lib/libcube4w.a', 'lib64/libcube4w.a'),
+              ('lib/libcube4w.%s' % SHLIB_EXT, 'lib64/libcube4w.%s' % SHLIB_EXT)],


only lib/ is fine

boegel · 2019-05-15T08:58:31Z

easybuild/easyconfigs/o/OTF2/OTF2-2.1.1-GCCcore-8.2.0.eb

+sanity_check_paths = {
+    'files': ['bin/otf2-config', 'include/otf2/otf2.h',
+              ('lib/libotf2.a', 'lib64/libotf2.a'),
+              ('lib/libotf2.%s' % SHLIB_EXT, 'lib64/libotf2.%s' % SHLIB_EXT)],


only lib/ is fine

boegel · 2019-05-15T08:59:42Z

easybuild/easyconfigs/s/Scalasca/Scalasca-2.5-gompi-2019a.eb

+]
+
+sanity_check_paths = {
+    'files': ['bin/scalasca', ('lib/libpearl.replay.a', 'lib64/libpearl.replay.a')],


only lib/ is fine

boegel · 2019-05-15T09:00:07Z

easybuild/easyconfigs/s/Score-P/Score-P-5.0-gompi-2019a.eb

+# http://apps.fz-juelich.de/unite/
+##
+
+easyblock = 'EB_Score_minus_P'


You can actually remove this, since it matches the software name?

Wasn't there a policy change at some point in the past to make the easyblock explicit?

A (long) time, we dropped the automagic fallback to trying with ConfigureMake (which was confusing since that always left you wondering which easyblock was actually being used if none was specified).

But as long as the software name matches the easyblock, there's no point in specifying it, since there's no ambiguity.

boegel · 2019-05-15T09:00:14Z

easybuild/easyconfigs/s/Score-P/Score-P-5.0-gompi-2019a.eb

+sanity_check_paths = {
+    'files': ['bin/scorep', 'include/scorep/SCOREP_User.h',
+              ('lib/libscorep_adapter_mpi_event.a', 'lib64/libscorep_adapter_mpi_event.a'),
+              ('lib/libscorep_adapter_mpi_event.%s' % SHLIB_EXT, 'lib64/libscorep_adapter_mpi_event.%s' % SHLIB_EXT)],


only lib/ is fine

geimer · 2019-05-15T14:44:29Z

@boegel W.r.t. the CI check: I don't have the complete picture yet when the check is desired and when it's not. If it comes down to whitelisting Bundles with an empty exts_list I can probably tackle this. If it is more complicated than that, I might be out of the game...

geimer · 2019-08-02T12:38:41Z

Test report by @geimer
SUCCESS
Build succeeded for 10 out of 10 (10 easyconfigs in this PR)
swat - Linux debian 9.9, Intel(R) Xeon(R) CPU X5550 @ 2.67GHz, Python 2.7.13
See https://gist.github.com/9915275afb38032ace9b6a4fd3158ae1 for a full test report.

geimer · 2019-08-02T12:42:54Z

This PR has been pending for so long that I could incorporate yet another version bump to the packages released yesterday 😃 I think it's now (finally) ready for prime time...

boegel · 2019-08-09T10:28:41Z

Test report by @boegel
SUCCESS
Build succeeded for 10 out of 10 (10 easyconfigs in this PR)
node3103.skitty.os - Linux centos linux 7.6.1810, Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz, Python 2.7.5
See https://gist.github.com/7fe6bb549c118da7cc8013167d5157cc for a full test report.

boegel · 2019-08-09T11:10:17Z

Test report by @boegel
SUCCESS
Build succeeded for 10 out of 10 (10 easyconfigs in this PR)
node2425.golett.os - Linux centos linux 7.6.1810, Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz, Python 2.7.5
See https://gist.github.com/17d21f2e0b70b84b5514f9495def5cb8 for a full test report.

boegel · 2019-08-09T11:46:58Z

Going in, thanks @geimer!

geimer added 8 commits May 16, 2018 12:44

Add OPARI2 2.0.3 easyconfig (GCCcore-6.4.0)

e6b06f2

Add OTF2 2.1.1 easyconfig + deps (GCCcore-6.4.0)

ab65fa8

Add PDT 3.25 easyconfig (GCCcore-6.4.0)

48ae425

Add CubeW 4.4 easyconfig (GCCcore-6.4.0)

de8eeb8

Add CubeLib 4.4 easyconfig (GCCcore-6.4.0)

41a83c4

Add CubeGUI 4.4 + deps easyconfigs (GCCcore-6.4.0)

ddfb03f

Cleanup

a7b46c7

Add Cube 4.4 bundle easyconfig (GCCcore-6.4.0)

c8175e3

easybuilders deleted a comment from boegelbot May 17, 2018

boegel reviewed May 17, 2018

View reviewed changes

boegel requested changes May 17, 2018

View reviewed changes

Renamed package Six to six as requested

8c7d1f9

geimer mentioned this pull request May 17, 2018

{perf}[foss/2018a] Score-P 4.0 + Scalasca 2.4 + deps (WIP) #6327

Closed

Don't try to build OTF2 Python bindings; it has to be done in a

760d196

different way

geimer mentioned this pull request May 17, 2018

{devel}[GCCcore/6.4.0] Qt5 5.10.1 + deps #6335

Closed

geimer added 3 commits May 18, 2018 10:22

Make CubeLib a build dependency of CubeGUI; it's properly rpath'ed

e70b39e

Add Score-P 4.0 easyconfig (gompi-2018a)

b95dc59

Add Scalasca 2.4 easyconfig (gompi-2018a)

e3873b1

boegel added the update label May 18, 2018

geimer mentioned this pull request May 19, 2018

GCC/GCCcore -ftree-vectorize breaks Mesa #6344

Open

Merge branch 'develop' of github.com:easybuilders/easybuild-easyconfi…

c1ff0e8

…gs into scorep_scalasca_update_hmns_mintc

boegel added this to the 3.x milestone May 9, 2019

geimer added 5 commits May 10, 2019 08:55

Merge branch 'develop' of github.com:easybuilders/easybuild-easyconfi…

b20b81a

…gs into scorep_scalasca_update_hmns_mintc

Remove Qt5-related easyconfigs that have been superseded

a4ff0b5

Bump SIONlib to v1.7.4 for GCCcore 8.2.0

c6df816

Build OTF2 with GCCcore 8.2.0 and bump SIONlib dependency

63b6c48

Build PDT with GCCcore 8.2.0

82f9e92

geimer added 5 commits May 10, 2019 13:51

Bump CubeGUI to v4.4.3 using CubeLib v4.4.3 and GCCcore 8.2.0

59664cb

Rework Cube convenience bundle

d46dd53

Add PAPI for GCCcore 8.2.0

350e8d1

Bump Score-P to v5.0 and update dependencies

77ef331

Bump Scalasca to v2.5 and update dependencies

82c2d98

geimer changed the title ~~{perf}[gompi/2018a] Score-P 4.0 + Scalasca 2.4 + deps (WIP)~~ {perf}[gompi/2019a] Score-P 5.0 + Scalasca 2.5 + deps (WIP) May 10, 2019

boegel requested changes May 15, 2019

View reviewed changes

geimer added 2 commits May 15, 2019 15:04

Consistently only use lib in sanity_check_paths

99b693a

Explain version number

090cadc

geimer added 3 commits June 17, 2019 14:08

Do not explicitly specify easyblock for Score-P

3eb1d63

Remove Cube convenience bundle as it seems to create confusion

1dec8da

Bump to latest releases; also HTTPS is finally working

6dce381

geimer changed the title ~~{perf}[gompi/2019a] Score-P 5.0 + Scalasca 2.5 + deps (WIP)~~ {perf}[gompi/2019a] Score-P 6.0 + Scalasca 2.5 + deps Aug 2, 2019

boegel approved these changes Aug 9, 2019

View reviewed changes

boegel merged commit ab85d17 into easybuilders:develop Aug 9, 2019

geimer deleted the scorep_scalasca_update_hmns_mintc branch August 9, 2019 12:49

boegel modified the milestones: 3.x, 3.9.4 Aug 21, 2019

migueldiascosta added the new label Aug 22, 2019

Flamefire mentioned this pull request Apr 16, 2020

{perf}[gompic/2019b] Score-P 6.0 and dependencies #10397

Merged

{perf}[gompi/2019a] Score-P 6.0 + Scalasca 2.5 + deps #6328

{perf}[gompi/2019a] Score-P 6.0 + Scalasca 2.5 + deps #6328

Uh oh!

Conversation

geimer commented May 16, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

boegel commented May 17, 2018

Uh oh!

boegel commented May 9, 2019

Uh oh!

geimer commented May 9, 2019

Uh oh!

geimer commented May 10, 2019

Uh oh!

geimer commented May 10, 2019

Uh oh!

boegelbot commented May 10, 2019

Uh oh!

boegel commented May 15, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

geimer commented May 15, 2019

Uh oh!

geimer commented Aug 2, 2019

Uh oh!

geimer commented Aug 2, 2019

Uh oh!

boegel commented Aug 9, 2019

Uh oh!

boegel commented Aug 9, 2019

Uh oh!

boegel commented Aug 9, 2019

Uh oh!

Reviewers

Assignees