Embed nrnunits.lib #3471
Embed nrnunits.lib #3471
Conversation
|
✔️ 496a655 -> artifacts URL |
|
There was a problem hiding this comment.
This was renamed because we use cpp_cc_build_time_copy on some of the directories, so nrnunits.lib was first set-up at configure time, but then cpp_cc_build_time_copy would clobber it at build-time, so to work around it, we just rename it.
|
✔️ 290387a -> artifacts URL |
|
✔️ 290387a -> Azure artifacts URL |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3471 +/- ##
=======================================
Coverage 68.40% 68.40%
=======================================
Files 682 682
Lines 116565 116574 +9
=======================================
+ Hits 79731 79747 +16
+ Misses 36834 36827 -7 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| configure_file(${PROJECT_SOURCE_DIR}/share/lib/nrnunits.lib.in | ||
| ${PROJECT_BINARY_DIR}/share/nrn/lib/nrnunits.lib @ONLY) | ||
|
|
||
| set(nrnunits_start "R\"qwerty(") |
There was a problem hiding this comment.
Optional...Could use a comment. Took me a while (and looking at the constructed embedded_nrnunit.lib file) to realize the reason for the start/stop idiom. I'd never seen this C++ feature before
Fix #3470.
We now configure both
nrnunits.libandembedded_nrnunits.lib, and embed the latter directly as astring_viewinunits.cpp.This is only used as a last resort (i.e. if all other methods of figuring out the path to a
nrnunits.libfile fail).The alternative would be to figure out the path of the binary executable at run-time, which would require too much platform-specific code.