conditional compiles for addons ...


#1

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…


#2

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).


#3

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…


#4

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.