Conversation
|
@alalazo I don't really understand the error message, can you have a look? |
| if generator == 'Unix Makefiles': | ||
| depends_on('gmake', type='build') | ||
| elif generator == 'Ninja': | ||
| depends_on('ninja', type='build') |
There was a problem hiding this comment.
I don't think this will work, since generator will always be Unix Makefiles at this point when reading the file, it isn't overwritten until it reads the subclass file. We could use a when spec, but we purposefully didn't include the generator in the spec since it doesn't change what gets installed. Also, I don't think gmake is specifically required, any new-enough make should work.
There was a problem hiding this comment.
Good point, what would be the best way to pull in the generator?
Something like depends_on('cmake generator="Ninja"') in package.py seems a bit redundant.
There was a problem hiding this comment.
I don't think we should add a variant to the cmake package since that will cause needless duplication of builds (cmake generator=ninja would be different from cmake generator=make). I have a vague idea of an approach that might work (using metaclasses) if the goal is to append a dependency on make or ninja to any CMakePackage based on the inspection of some class attribute. I need to check the details though to be sure it can be implemented smoothly.
|
Closing since this won't work right now, but linked this PR in spack/seps#3 to account for this use case while we design extensions on the build systems. |
3 participants
I came across a system with an ancient gmake....