conditional compiles for addons ...

Hi All, this is what I’d like to do:
I have a physics addon, and i have an independent binary file / streaming addon. The physics addon uses the binary file addon to save and load replays. Instead of making the binary file addon a requirement for the physics addon, I’d like to make it so that if the binary file addon is not on the users system, the physics addon does not have replay functionality (As it’s rarely needed) - and I can’t get this system to work.

I tried using the addon defines, but they only work if the entire physics addon is defined in header files. I.e. putting #ifdef OF_ADDON_USING_BINARY in the physics header files it all works fine.

But obviously if I put the #ifdef in any physics .cpp files it doesn’t work as expected. The cpp files get compiled independently including only what they explicitly #include. Since OF_ADDON_USING_BINARY is possibly defined only in testApp.h (or any other project file), physics.cpp does not see it. So it compiles without the define (even if you declared it) and you never get the functionality.

I also had this problem with ofxSimpleGUI. it was hardcoded to handle XML files and openCV objects etc. And even if I dont use openCV in my project (and obviously don’t need the openCV controls) I still need to use openCV just to get the ofxSimpleGUI to compile. In that case I put the whole ofxSimpleGUI in header files for it to work with the #ifdef, but obviously that is an ugly solution.

Obviously you could make the openCV controls a completely separate addon, and the xml stuff a completely separate addon, and the physics replay management a completely separate addon. But then the maintenance gets more painful, and its ultimately more work for the user. i.e. If you have openCV and XML and simpleGUI installed, their relevant controls should all be there I think. You shouldnt have to go and also download the simpleGUI-openCV addon and the simpleGUI-XML addon etc. I think its a much simpler option if addons provide extra features depending on what addons you currently have.

I’ve been thinking about how this could be possible, and the only thing that I could come up with is to have a predetermined project file (“e.g. UsedAddons.h”) which is filled per project (but always has the same name). And you list all of your addon defines in there. And all addons include that file too to see what addons are being used and act accordingly…

If anyone can thing of an alternative way (or any comments on this method) please let me know…

the way to normally manage things like this is to have global defines that get passed to the compiler. for gcc (Code::Blocks/Xcode) you’d edit the Additional C++ Compiler Flags… section of your GUI builder tool and add -DMY_SYMBOL -DMY_OTHER_SYMBOL etc. (or if you’re using oldschool makefiles, add these to the CFLAGS variable).

but, the procedure for doing this varies from IDE to IDE and can be cryptic, especially for newbies (i assume this was the reason for the #define OF_ADDON_USING_BLAHBLAH procedure).

Yea the concept of #define OF_ADDON_USING_BLAHBLAH is a good one, but if the addons themselves don’t know about it, you can’t really do the conditional compiles that you need to doin the addon, and end up having to hack the addon code depending on the project… which obviously is not a nice solution… I personally vote for the “MyAddons.h” solution :stuck_out_tongue: but its no use if its not set as a strict convention…

Hi @memo
Did you ever get something implemented for this topic?

I’m currently using damian’s approach for a big addon I made (https://github.com/PlaymodesStudio/ofxOceanode), but I hate to have to get a lot of addons if you don’t intend it to use (osc, midi…).
It’s a little bit confusing if you want to add for example osc, and you have midi already, to update the project with project generator and then go to Xcode and then define USE_OSC and USE_MIDI.

Sorry to come back to these old post, but it matches perfectly what I’m trying to accomplish.

Best.
Eduard.

Hi again @memo

I found a way to deal with that.
What i do is an only .mk file addon, that sets the macros in xcode automatically, and also adds the proper addons (ofxMidi or ofxOsc in my case).
Example at: https://github.com/PlaymodesStudio/ofxOceanode_Osc

Note that only works with project generator from of0.11 release.

Wanted to share my solution for this; it’s a change to the project generator where a -D flag will automatically add define names for each included addon into the generated project, ie. ofxMIDI and ofxOsc = OFXADDON_OFXMIDI and OFXADDON_OFXOSC

#ifdef OFXADDON_OFXMIDI
// my midi addon specific code
#endif

Also added it to the project generator frontend and made a pull request - there is a Release for OSX in the fork here if you would like to test it without compiling the entire app:

2 Likes

hey @EduardFrigola,
does this should work on Windows with VS2017 too?

I’ll like to let my addon ‘static’, and set some behaviors or use of some (optional) addons when creating the project with PG.

I tried to set my own file with this line on the addon_config.mk located on my myAddon/myProject:

# defines that will be passed to the compiler when including this addon
ADDON_DEFINES = INCLUDE_FILE_BROWSER_IM_GUI

Then I created the project with PG,
but VS is not acting as if the expected line was on myAddon.h:
#define INCLUDE_FILE_BROWSER_IM_GUI

I commented the other lines like # ADDON_DEPENDENCIES = ofxOsc
because there’s no problem that ofxImGui is added to my project to allow compile, even if not required.

I would like to test using the @autr PG, but is for macOS, so I need to compile for Windows…

Any idea?

Yes it should work.
addon_config.mk has to be located in the root addon folder, not into the project folder.
If you need configuration per project, I think you have to use config.make inside the project. There you can set PROJECT_DEFINES = INCLUDE_FILE_BROWSER_IM_GUI

1 Like