-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Re-work shared vs. static builds (Universal Variants) #2492
Comments
I think this is really going somewhere. The only thing that doesn't convince me out of the box is the implementation with fake dependencies in a base class, as we may find something cleaner. But having globals for certain properties definitely makes sense. We may even provide a spack globals set library-type=static Does anybody see use-cases that would be negatively affected by this proposal? Currently I can think only of artifact cases, that would never happen in a real production environment. |
In general, I think we should avoid building additional machinery if
etisting stuff can be used to do the job.
…On Dec 6, 2016 7:02 AM, "Massimiliano Culpo" ***@***.***> wrote:
I think this is really going somewhere. The only thing that doesn't
convince me out of the box is the implementation with fake dependencies in
a base class, as we may find something cleaner. But having globals for
certain properties definitely makes sense.
We may even provide a spack globals command to set or query them from cli
like:
spack globals set library-type=static
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2492 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AB1cd61YxxUtuVmSWe3iiAztFb65xNQYks5rFU7HgaJpZM4LFUY7>
.
|
That's debatable, but my point is that the implementation would be a stretch of the dependency model, at least logically. Anyhow I consider this a minor issue at the moment. |
My only objection to this is that the relationship is actually more complicated than what's allowed by the dummy dependency. Suppose we have library_type and it can be one of:
By using a dummy dependency for "global" properties like this, you force builds with any difference in global settings to be completely separate. So the more things you add to the I like the fact that the global enforces consistency, and we've discussed doing something like this for compilers in #3296 with virtual dependencies. I think that a potentially better solution may be offered by the new concretizer (coming real soon now™). Once we have concretization expressed as SAT, I think it will be fairly easy to add additional rules to the solve for things like "packages that have |
I would say that our thinking has evolved since this Issue was posted. In particular, #2644 provides similar functionality and is much simpler (and also implemented). At this point, we are waiting on #2386 as a prerequisite to clean up shared vs. static builds. Might universal variants be used for something else, or should this issue be closed? My gut feeling is that bottom-up forwarding of variants feels wrong. In the world of build systems, this practice is frowned upon; (i.e. features enabled/disabled based on what However... it is worth noting that some packages (i.e. a random assortment) use this kind of bottom-up forwarding of variants in an ad-hoc manner. We should at least keep around the observation that things can be forwarded bottom-up or top-down. Should this Issue be closed? |
@davydden @adamjstewart @alalazo @tgamblin
This is a continuation of #2380. It's in a new thread because the proposal now goes far beyond documentation. The idea would be to Create a dummy package (call it
spack
for now) with a multi-valued variant (#2386; call itlibrary-type
for now taking enum valuesshared
andstatic
). Then make the base classPackage
depends_on('spack')
(#2466) by default. This will have the following effects:Packages should look at
spec['spack'].library_type
to figure out whether they should eithera) build shared libs (or static libs with
-fPIC
-or-equivalent)b) build static libs
Users can set up all of Spack for either shared or static mode my making an entry for
spack/build_type
inpackages.yaml
. Alternately, they can write^spack@build-type=xxx
directly on the command line.This proposal solves a serious usability problem of all our other
shared
vsstatic
proposals: that users will have to put+shared
or+static
all over their builds and specs --- but ONLY for packages that build binaries. It would have worked out fine for most users, but been a royal PITA for Cray users.We can do other "universal variants" this way as well. It is much cleaner than trying to forward variants from the top of the DAG. (Or we can attach less-than-universal variants to dummy packages that are only depended on by SOME packages.)
The text was updated successfully, but these errors were encountered: