After successfully feeding JUCE as a static library to Unreal Engine 4 I'm still having issues when including lib to UE4 project headers.
I'm having this error: myue4project.generated.cpp(157) : error C3861: 'check': identifier not found
Here's this line.
I've found this #undef at juce_win32_WASAPI.cpp https://goo.gl/msQ07D , but I'm not sure it's the only one.
How do I handle that issue? Can I remove undef and rename check to, say, check_juce?
Would that effect crossplatform usability? AFAIK Mac can work different here.
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..
Thanks, Jules, anything works outstanding now.