Details
Diff Detail
Event Timeline
I don't mind, but please let Zack or Reid review this.
The question is: do we need to remove all traces of windows support from tests, or just disable check-fuzzer on the bot and remove only the parts that are blocking the refactoring.
First we should remove check-fuzzer from sanitizer-windows. That means patching zorg and a buildmaster restart. Otherwise, the bot will go red because of a missing target.
@rnk That's nothing I could do, right?
In any case, if we were to leave Windows support, I think redefining CMAKE_CXX_LINK_EXECUTABLE is definitely not the way to go.
It already caused a few problems (e.g. having to change the output directory), and will cause more.
If anything, even moving the compilation to LIT, so that the driver would be able to insert the appropriate libraries, is better.
Is there an option to make check-fuzzer a no-op on windows?
This way we won't have to touch the bot (and then touch it again, when windows is reinstated)
@kcc of course anything is possible. Should we though? Pretending that tests pass when they don't seems like a bad idea.
Why do you think that? If we want to keep the logic of where clang's compiler-rt libraries are within the clang driver, this is what we have to do. Otherwise we have to duplicate the logic that -fsanitize=foo uses to find clang's builtin libraries.
Which do you guys prefer, duplication or this complicated CMake logic to make Windows appear more like Posix?
It already caused a few problems (e.g. having to change the output directory), and will cause more.
I'm not familiar with this, you probably explained it somewhere else but I haven't had time to read.
If anything, even moving the compilation to LIT, so that the driver would be able to insert the appropriate libraries, is better.
That would be nice, it would make libFuzzer tests look more like compiler-rt sanitizer tests.
We will have to do something of this sort anyway once we make 'check-fuzzer' a part of 'check-all' on Linux and Mac.
We have to wait for Galina to do master restarts, but the logic is probably pretty easy to remove from zorg/zorg/buildbot/builders/SanitizerBuilderWindows.py.
That would be nice, it would make libFuzzer tests look more like compiler-rt sanitizer tests.
I think so too, I've just written an email arguing for it.
Which do you guys prefer
I prefer moving compilation commands to LIT.
Unit tests would still remain, but for them I think it's easier to duplicate the logic and specify all the dependencies in CMake, as done already in all sanitizers.
@kcc Does it mean you would be OK with the change moving the compilation commands to LIT, and only compiling unit-tests in CMake?
I'm not familiar with this, you probably explained it somewhere else but I haven't had time to read.
I was referring to https://reviews.llvm.org/D27870
I would still suggest to make check-fuzzer a no-op on Windows so that we don't need to touch the windows bot configs now.
Agreed, if both of you are blocked and just need to move on, and there's no definitive timeline for when a master restart will happen, then just making it a no-op until we can get the step actually removed seems like an immediate way to get unblocked.
OK great will probably land after https://reviews.llvm.org/D36295 to avoid conflicting with myself