Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configuration scopes and placement of packages.yaml #149

Open
tmadlener opened this issue Jan 14, 2021 · 2 comments
Open

Configuration scopes and placement of packages.yaml #149

tmadlener opened this issue Jan 14, 2021 · 2 comments

Comments

@tmadlener
Copy link
Contributor

In fact this is more an issue for key4hep-doc, but issues are not enabled there, so I am posting it here, also because this might be the first thing people consult when running into the same problem as I just did.

The issue

Following the instructions, the config/packages.yaml should be placed in spack/etc/spack/. However, this can lead to problems, especially if users have a user level packages.yaml configuration in ~/.spack/. The reason is that this user level configuration settings take precedence over the settings that ship with this. See: configuration scopes.

The problem I am currently running into, is that I have a

packages:
  all:
    variants: cxxstd=17

in my user configuration which interferes, with the currently shipped packages.yaml, leading to an unsatisfiable variant constraint:

Input spec
--------------------------------
 -   key4hep-stack

Concretized
--------------------------------
==> Error: An unsatisfiable variant constraint has been detected for spec:

    [email protected]%[email protected]~ipo build_type=RelWithDebInfo cxxstd=17 arch=linux-ubuntu20.04-broadwell


while trying to concretize the partial spec:

    [email protected]%[email protected]~ipo~motif~opengl~python~qt+threads+vecgeom~x11 build_type=RelWithDebInfo cxxstd=11 arch=linux-ubuntu20.04-broadwell
        ^[email protected]%[email protected]~doc+ncurses+openssl+ownlibs~qt arch=linux-ubuntu20.04-broadwell
        ^[email protected]%[email protected]+libbsd arch=linux-ubuntu20.04-broadwell
            ^libbsd
        ^[email protected]
            ^[email protected]
            ^[email protected]
            ^[email protected]%[email protected] arch=linux-ubuntu20.04-broadwell
            ^[email protected]
            ^[email protected]
            ^[email protected]
            ^[email protected]
            ^[email protected]
            ^[email protected]
            ^[email protected]
            ^[email protected]
        ^[email protected]%[email protected]+optimize+pic+shared arch=linux-ubuntu20.04-broadwell


geant4 requires clhep variant cxxstd=11, but spec asked for cxxstd=17

The problem can be solved in several different ways in this case, and is in fact most probably caused by the spack concretizer (so should be less severe in the future, hopefully). The underlying problem is that geant4 defines some desired variants

geant4:
variants: ~qt~opengl+vecgeom

Apparently, the cxxstd=17 variant is not added to this, even it should be for all packages. Hence only clhep gets the cxxstd=17 requirements from the user level configuration, which in turn leads to the above error.

Immediate solutions:

  • add cxxstd=17 to the variants of geant4 in the packages.yaml that we ship here
  • remove the cxxstd=17 variant from the packages: all section in the user level packages.yaml

Open questions:

Should we consider updating the instructions to install the shipped packages.yaml somewhere, where it takes precedence over user settings to ensure that we have a consistent build everywhere regardless of user settings?

@vvolkl
Copy link
Contributor

vvolkl commented Jan 14, 2021

That's strange, I would have expected that your setting of the cxxstd would be applied to geant4. This could be a bug in spack. For the immediate solution, I think nothing speaks against using cxxstd=17 for geant4 (or actually all packages like you do)

Regarding the interference from ~/.spack/, the same problem applies to .bashrc and other ways people can change their system. I think it should be documented, but having the possiblity to configure spack is also a feature.

Note that now also spack is installed on cvmfs for a "just works"-type setup (although the same precedence considerations apply)

@tmadlener
Copy link
Contributor Author

tmadlener commented Jan 15, 2021

That is indeed a good point about spack seemingly not applying the "global" cxxstd variant to geant4. I will check if this is indeed a spack bug (see spack/spack#20936).

Regarding the interference from ~/.spack/, the same problem applies to .bashrc and other ways people can change their system. I think it should be documented, but having the possiblity to configure spack is also a feature.

Yeah, I agree. So we should document this. I will open a pull request for the key4hep-doc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants