Build-specific source files


#1

Hi,

Likely newby question. But I looked around a bit and couldn’t find anything in Introjucer or the forum regarding how to have source files that are specific to a given Build platform. For example, I created a little bit of helper Objective C code to deal with a couple of iOS-isms that Juce doesn’t yet address (at least as far as I can tell since I’m pretty new to Juce) such as detecting the virtual keyboard popup / popdown. Code works fine with Juce classes, but of course doesn’t come into play for Builds for other platforms (Linux, MacOS etc). So as I refine my project it would be nice for Introjucer to manage the inclusion (or not) of such files into the relevant build configuration (Xcode project, Makefile, etc) so I don’t have to manually tweak the Xcode projects or whatever with each revision. I could maybe do something like this on my own with #ifdef but it seems there would be a more elegant way of handling this.

Any feedback on this will be very helpful, even if it’s just to get hep to the proper, “jucy” way of doing things.

best regards,


Platform-dependent compilation of source files
#2

#if is the best way. My personal preference is that build specific sources should always go in the project, even when the file is not used on a particular platform.

This way, all the sources are visible in the IDE. This raises programmer awareness that other platforms are supported. It also makes it easier to do searches through the entire source code base. Imagine doing a global search and replace on common function but not finding it in a platform-specific .cpp. Or if you want to search to find where a function is used.

You can do this by marking the file in a way where its not compiled on a particular IDE (for example “Excluded from build” in Visual Studio) or an easier way is to just use the JUCE #if on the contents of the entire file:

#if JUCE_MAC
#if JUCE_IOS
#if JUCE_MSVC

et cetera.


#3

Thanks! I will try the #ifdef approach, because what I am trying to avoid is needing to go an re-tweak different IDE setups after I retouch things with Introjucer. My only concern here is feeding “.mm” files to something that doesn’t like but we shall see what happens … Thanks again for your quick response!


#4

I'm currently making a cross-platform control panel for a hardware product and I'm considering this issue.

I can #ifdef out platform-specific code that I write, which feels like the right thing to do. However, I'm bringing in external platform-specific code and it feels wrong to be putting #ifdefs round their code.

I could pull in their code using an wrapped include of my own:

MyFile.cpp

#ifdef _WIN32
#include "TheirFile.cpp"
#endif //_WIN32

... but then it wouldn't appear in the project.

Wondering if anyone else has a cleaner solution?


#5

I use that trick throughout the library, and am a big fan of it!

The alternative is for the choice of build files to be obfuscated away inside build scripts + projects, which I think makes it less easy to see what's going on that simply having a master file which includes the appropriate files depending on the platform you're building for.