On 12/16/2016 7:55 AM, Brad King wrote:
It looks like this was added in commit 44726714322ca0b75628e234229f4583a480d7ec
when support for asan was first added. Bill, do you recall why?
I don't recall exactly. I guess I figured if you were running asan you
might as well check for leaks as well.
On Fri, Dec 16, 2016 at 09:46:22 +0100, Yves Frederix wrote:
> Although I am not fully convinced that the above might actually happen
> in 'normal' practice, I do agree that it is a risk that should not be
> introduced simply to get less verbose output for the clean step (my
> use case). Pulling
Hi Folks,
FYI, after today I'm heading out for vacation and will likely not
be responsive until at least Jan 9.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the
On 12/16/2016 04:35 AM, Sylvain Joubert wrote:
> The issue is that CMake appends its own "detect_leak=1"
>
> I see two possible fixes here:
> 1- Since "detect_leaks=1" is the default, we can simply not append
> it to the options and make sure the user options are last
It looks like this was
Hi everyone,
I've setup some sanitizer builds on my project and I'd like to have two
separate builds for asan and lsan, meaning I want to disable leak detection
in the asan build.
I've managed to correctly setup the CTEST_MEMORYCHECK_SANITIZER_OPTIONS
with "detect_leaks=0" and at runtime
> Flags for other generators can cause the `clean` to not actually happen.
> For example, with make `cmake --build ... --clean-first -- -i` can cause
> the clean to silently fail and then it isn't really a clean build. Or
> the `-t` flag which skips running commands and instead just touches
>
