All CMakePackages depend on CMake

[adamjstewart]

@alalazo Is there any reason we can't add depends_on('cmake', type='build') to the CMakePackage base class? It seems silly to have to add it to every package that extends it.

[tgamblin]

We might need to adjust the way directives store metadata for this, but I think it's a good idea.

[alalazo]

@adamjstewart I didn't do that because of what @tgamblin said, see here.

I think I may have an idea anyhow how to do that: instead of using inspect.stack we may:

1. register at class construction time all the directives in a global attribute within the directives module
2. flush them into the class being constructed using PackageMeta

Does that make sense to you @tgamblin ?

[citibeth]

I thought of this too. But I'm doubtful for two reasons:

1. Different packages have different CMake version requirements. So there is no one-size-fits-all depends('cmake') command.

2. We continue to go down the path of making things more implicitly automagic in order to save a few lines in the package.py files. I continue to think that is a dangerous idea --- at least something we should have a serious discussion about. So far, we have not had that discussion.

[alalazo]

We continue to go down the path of making things more implicitly automagic in order to save a few lines in the package.py files. I continue to think that is a dangerous idea --- at least something we should have a serious discussion about. So far, we have not had that discussion.

What I propose above involves substituting the use of inspect.stack with meta-classes. It's not additional machinery, just a refactoring of the existing one that permits to inherit across different module files (currently you can't).

[citibeth]

I have mixed feelings: 1. I like the idea of being able to inherit `depends_on()` declarations --- even if I'm not thrilled about its application in this particular case. 2. I don't like things that require meta-classes to implement: we will lose 99% of Python programmers at that point. But given that this is buried deep within Spack and not user-visible, I'd give it a pass --- as long as we can't think of any way to get the desired functionality without meta-classes.

…

On Tue, Dec 6, 2016 at 7:12 AM, Massimiliano Culpo ***@***.*** > wrote: We continue to go down the path of making things more implicitly automagic in order to save a few lines in the package.py files. I continue to think that is a dangerous idea --- at least something we should have a serious discussion about. So far, we have not had that discussion. What I propose above involves substituting the use of inspect.stack with meta-classes. It's not additional machinery, just a refactoring of the existing one that permits to inherit across different module files (currently you can't). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2466 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB1cd31-LjxVQL-3zZs4EyfLkgXc_S3Oks5rFVEvgaJpZM4LDFSE> .

[adamjstewart]

Different packages have different CMake version requirements. So there is no one-size-fits-all depends('cmake') command.

@citibeth This won't be a problem. You can always add depends_on('cmake@1.2.3:') to your package to make a more specific version constraint. Spack won't complain that you used depends_on('cmake') twice.