Hi all
Being new, I figured I’d ask:
It seemed advantageous to try add a “feature” to MaskCreator which allows it to add the newly created mask to the outgoing config - this works nicely where I am here, but needed mods to Detector.hpp and PixelDetector.cpp in src/core/detector (the latter might be avoidable) - made me wonder:
Is there a rule of thumb for when edits to core sections are reasonable?
Also, is there a generic approach to new features in existing code, should they get a flag to enable them and be disabled by default, so as to preserve existing behaviour?
Otherwise, thanks for this, beautiful piece of software (minor issues with CMAKE where I am, but nothing dramatic).
All the best,
Jens
Hi Jens,
welcome to Corry and thanks for your question.
If you like you’re also welcome to join our Mattermost channel:
https://mattermost.web.cern.ch/corryvreckan
Regarding your question: I don’t think we do have a rule of thumb but decide on a case by case basis. And generally try to avoid breaking backwards compatibility.
Usually, we manage by adding a new configuration parameter when adding a new feature, see e.g. here: AnalysisDUT: add new paramete
The default value of the parameter then guarantees backwards compatibility, such that users pulling the latest version and don’t need to update their config files.
With respect to the mask creator:
The way it’s implemented now, it creates a new mask file if you didn’t provide one yet in the geometry description, else it will append the newly masked pixels to the given mask file. Isn’t that what you’re looking for? So yes, it involves one manual step of adding the newly created mask file to your geometry. Is that what you mean?
Lastly, it’s great to hear you like the software so far. If you think the issues related to CMAKE are worth sharing - or even better - worth fixing, please be encouraged to open an issue or a merge request in case you have a proposed solution.
Cheers,
(another) Jens