When Visual C++ encounters an auto which needs to be const, it will interpret it as const auto.
GCC / Clang doesn't have this personality, so many autos will need to be changed to const auto where applicable.
ofxPlugin
ofxPlugin lets you write DLL's which you can load into your openFrameworks app (e.g. a camera plugin, or a plugin with some new nodes for Rulr).
The function to load plugins is based on Windows specific code. It's probably quite easy (e.g. 2 or 3 lines) to make this work with dylib files also, but even easier is to #ifdef guard out functions such as:
Copy the code for these into the main project (i.e. statically linked)
HAS_OFXADDONNAME
Some parts of the code presume that there's a preprocessor flag for each available addon (to declare the availability of that addon globally across the codebase). You might want to add at least:
elliotwoods
commented
8 years ago
Some notes on porting:
autovsconst autoWhen Visual C++ encounters an
autowhich needs to be const, it will interpret it asconst auto.GCC / Clang doesn't have this personality, so many
autos will need to be changed toconst autowhere applicable.ofxPlugin
ofxPlugin lets you write DLL's which you can load into your openFrameworks app (e.g. a camera plugin, or a plugin with some new nodes for Rulr).
The function to load plugins is based on Windows specific code. It's probably quite easy (e.g. 2 or 3 lines) to make this work with
dylibfiles also, but even easier is to#ifdefguard out functions such as:https://github.com/elliotwoods/ofxPlugin/blob/master/src/ofxPlugin/FactoryRegister.h#L94
Current plugin examples are:
For the OSX port we can either:
HAS_OFXADDONNAME
Some parts of the code presume that there's a preprocessor flag for each available addon (to declare the availability of that addon globally across the codebase). You might want to add at least:
HAS_OFXGRABCAMHAS_OFXSINGLETON