The place in the juce codebase where that macro is used is deep inside the cpp files, not the headers, so this code should all live in its own compile-unit.. What on earth are you doing that would mean that your own code follows it in the same compile pass, and thus gets effected by the macros that it defined/undefined internally?
Epic Games has it's own complicated module targeting system, so I can't exactly tell how is it getting effected. 'generated' files are generated automatically by an ue4 toolset so fighting it's consequences is what's left to me.
I could use juce inclusion at cpps only which gives no errors, but that's not really comfortable.
Well, I could (and probably should) change that macro name to something less likely to cause a collision. But the reason I didn't bother was because I couldn't imagine what kind of weird, off-piste build people could have that'd actually include all the juce .cpp files (a vast amount of code!) rather than just building them as compile units.
I own a license for a 4-ish days so I haven't yet figured out which parts of juce_core are unnecessary for me and just made a static lib with core.
Still if it looks like necessary parts (like sound output) are defining/undefining check macro and adding separate compile units won't help as ue4 would still make a 'generate.cpp' which would cause trouble.
Ah, I had a quick search of the codebase, and you're obviously talking about the "#undef check" that happens in juce_StandardHeaders.h, not the one in the cpps. That makes more sense!
Looking a bit further, it does seem that I can safely remove that undef if I rewrite some bits of public header code to work around this name-pollution. There are some uses of the symbol "check" inside the juce implementation too, but in there I can undef it privately without affecting anything else.
I've pushed this to github now if you want to give it a try..