build regression for unsupported CXX=nvcc
Issue #324
resolved
CI reveals that our CXX=nvcc configuration has stopped working:
https://upc-bugs.lbl.gov/upc_tests/config.php?date=2020-02-24&config=EX-dirac-ibv-nvcc-dbg
It fails to get through the new CUDA configure logic (I had to manually tweak the old nobs CUDA logic to make this case work).
This is an unsupported configuration for building the UPC++ library. The only reason we test this way at all is it's the most convenient way to get test coverage for the nvcc compiler wrapper parsing our UPC++ public headers, which we do want to support (and has been broken in the past - issue #274).
We should hack together something after feature freeze to restore this test coverage, even if it's never merged to the public branches.
Comments (5)
-
-
Proposed fix in pull request 180
-
- changed status to resolved
configure: resolve issue 324
This commit adds logic to
configureto use hard-coded values forUPCXX_CUDA_{CPP,LIB}FLAGSwhenCXXisnvcc(a configuration we do not officially support).This is sufficient to
make checkwithCXX=nvccand a manual run of theEX-dirac-ibv-nvccpushbuild config.→ <<cset 985fc96eca63>>
-
-
fixup: configure: resolve issue 324
This commit fixes a regression on (at least) macOS due to use of bash syntax not supported in bash 3.2 (our documented floor version).
→ <<cset 0a8432a91123>>
- Log in to comment
- Assignee
- Type
- Priority
- Status
- resolved
- Component
- Build/install scripts
- Milestone
- 2020.3.0 release
- Version
- Development Branch
- Votes
- 0
- Watchers
- 2
Note to future self: nvcc special-casing was added to nobsrule.py in (at least) the following commits: 9665de5 0107d1c 70cd43b
If I read the first of those correctly, getting past the configure-time failure looks to be simply a matter of "canned responses" in place of the current scraping logic when
CXX=nvcc:I didn't try to parse the other tweaks in-depth, but at least the pthread and Open MP flags are orthogonal to current build infrastructure until we address issue 319