On Sun, Jun 11, 2017 at 11:51:31PM +0200, Michael Soegtrop wrote:
Dear Bryce,
Also, in general, I know we've been apt to pull stuff into the main codebase but going forward as much as possible let's try to keep external dependencies completely external, with detection logic in cmake. The more we can slim down the codebase the easier it'll be for new folks to learn and less work it'll be for busy old timers to maintain over the long run.
The piece I suggested is exactly that: cmake code which detects and implements sanitizer support. But it is just 10 or so cmake files and can also be copied.
If it is entirely inside the cmake directories, then that does remove most of the worry, although 10 files sounds like a lot of cmake...
So, as a rule of thumb, you'd want to see at least, say, 3 people committing to watch and follow up on issues found by a particular tool, if adoption of the tool is going to be invasive in terms of infrastructure requirements or adjustments to development processes.
I think the sanitizers are different. It is more a tool to help developers debug their code in case they see strange behavior like Debug/Release mode deviations.
They're not different, same concept applies - make sure other people besides yourself will be committing to use it before you add it to the repo.
I don't mean to pick on this tool in particular, there's just been a bit of a history of tests, build systems, frameworks, and so on being championed by one person but never really catching on beyond them, so that when their attentions moved on the bits were left in place to atrophy.
Bryce