Ticket #3992 (closed: fixed)
CMake: Nexus location isn't picked up properly
| Reported by: | Russell Taylor | Owned by: | Russell Taylor |
|---|---|---|---|
| Priority: | major | Milestone: | Release 2.0 |
| Component: | Infrastructure | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Tester: | Michael Reuter |
Description
It turns out we've been relying on it being in a standard location, or at least in the same location as something else we're including (e.g. boost, poco in Third_Party). As soon as it's somewhere else (the specific example was /opt/nexus), the build fails.
Change History
comment:2 Changed 9 years ago by Russell Taylor
Move Nexus include and library finding up to common setup as it's needed by multiple packaged. Re #3992.
Changeset: 6b3a56af23a318e9ddf0d3341d1c4793ceb70c7e
comment:3 Changed 9 years ago by Russell Taylor
Move up Qt finding because DarwinSetup needs a variable set by it. Re #3992.
Changeset: a1ed5d56be1b7c6d38d9f33607dbb2e12455fe6b
comment:4 Changed 9 years ago by Russell Taylor
- Status changed from accepted to verify
- Resolution set to fixed
To test: move the nexus includes & library somewhere different & non-standard. Try a fresh cmake config. Watch it fail to find Nexus. Edit the NEXUS_INCLUDE/NEXUS_LIBRARIES cmake variables by hand (in the cmake gui or ccmake) and the finish the configuration. Previously, Kernel would fail to build because it wouldn't find napi.h. Now it should be fine.
comment:5 Changed 9 years ago by Michael Reuter
- Status changed from verify to verifying
- Tester set to Michael Reuter
comment:6 Changed 9 years ago by Michael Reuter
- Status changed from verifying to closed
Following the given prescription, moving the includes and libraries does cause the configuration to break. Then specifying the appropriate variables, the configuration completes correctly. With the configuration complete, the framework does build.
