Added -DBits cmake option for selective build, w/ auto-trimming of built backend interfaces#595
Added -DBits cmake option for selective build, w/ auto-trimming of built backend interfaces#595anderkve wants to merge 13 commits into
Conversation
…trimming of backend interfaces. - Added new CMake option for the user to select which Bits to include in the build. (ScannerBit is always included.) Example: "cmake -DBits=ColliderBit;DecayBit .." will ditch all Bits except ColliderBit and DecayBit. - Also added system for automatic filtering of the backend interfaces (frontends), so that we only build the frontends for the backends that are actually used by the Bits we include in our build. - Added a new make target "make list-backends" which lists all the available backends, their make targets, and what Bit(s) they are relevant for - In our cmake system, replaced some embedded Python code with native cmake code for significant speed increase when checking the ditch status of build elements.
Similar in spirit to the "make list-backends" target.
|
Suggesting both @ChrisJChang and @pstoecker as reviewers, but no need for both of you – whoever gets time first can look at it. (Most of the new code is just two new python helper scripts for making the lists and some new cmake utility functions.) |
|
I have not looked at the code yet, so the answer might be in plain sight. Just a thought at the beginning I know it is bad usage and probably very unlikely to happen: What is the behavior if you have some "Bit" explicitly ditched via
Personally I would make it an error rather than silently swallow the conflicting configuration EDIT: Fixed typo: to be clear, if have not started reviewing yet |
|
Goot point, @pstoecker. Currently there is no error, -Ditch takes preference over -DBits. But you are right that just making it an error would be neater. I'll do that. I've just now found a couple of other tweaks I want to make to this system, so you can anyway hold off the review until I've implemented those things. Will let you know when it's ready! |
…nterfaces (frontends) and ditching of backends.
|
@pstoecker Now all the functionality should be in place, I think. But I will revise the code a bit (get rid of overly verbose comments, etc.), so don't do a detailed read of the code yet. But if you want to test the functionality, it should be ready for that. |
|
OK, I think this one is ready for testing + review now. |
This PR attempts to make it easier for the user to only build the parts of GAMBIT they actually need for their given project.
Added new CMake option for the user to select which Bits to include in the build. (ScannerBit is always included.) Example:
cmake -DBits=ColliderBit;DecayBit ..will ditch all Bits except ColliderBit, DecayBit and ScannerBitAlso added system for automatic filtering of the backend interfaces (frontends), so that we only build the frontends for the backends that are actually used by the Bits we include in our build.
Added a new make target
make list-backendswhich lists all the available backends, their make targets, and what Bit(s) they are relevant forAdded a similar new make target
make list-scannerswhich lists all the available scanners in the cmake system, and where relevant, their make targets.In our cmake system, replaced some embedded Python code with native cmake code for significant speed increase when checking the ditch status of build elements.