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.

Sign up for GitHub

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

Jump to bottom

match bootstrapped compiler to architecture #14059

Merged
merged 1 commit into from
Dec 15, 2019
Merged

match bootstrapped compiler to architecture #14059

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
1 change: 1 addition & 0 deletions lib/spack/spack/package.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1509,6 +1509,7 @@ def bootstrap_compiler(self, **kwargs):
)
if not compilers:
dep = spack.compilers.pkg_spec_for_compiler(self.spec.compiler)
dep.architecture = self.spec.architecture
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 nitpicks @becker33:

  1. Should we be this specific, or should we use the family? I'm just curious because I thought there was a discussion where when we detect compilers we add the family as the target.
  2. What about cross-compiled environments? Should we use the frontend family if the target is the backend? Given that I'm not sure we can handle that situation properly now anyway I am not sure I care for this PR, but I thought I'd ask.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could put os=fe target=fe in, although that would require a bit more refactoring. Not too much though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tgamblin on point 1, the target of a compiler and the target for which a compiler package is built are different things. We definitely want the compiler target to be the family, because that controls which processors it knows about for cross-compilation. But some users probably want their compilers built for the fastest architecture they can, to speed up build times. I don't know how much of a difference in build time it makes to build the compiler for broadwell vs x86_64, but it could be enough to be worth something.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I will merge this for now (cc: @scottwittenburg), and this may not even be an issue when compilers are dependencies. I definitely think there is some stuff we need to flesh out for compiler modeling.

The way we currently handle the target attribute is not quite as clear about where the compiler runs and what it targets as I'd like it to be -- I think we use the target for both...

# concrete CompilerSpec has less info than concrete Spec
# concretize as Spec to add that information
dep.concretize()
Expand Down