Project encapsulation and addons.make referencing addons not in $(OF_PATH)/addons

In an effort to fully encapsulate a project along with its dependencies, we are looking to use $(SRCROOT)/addons instead of the usual spot. I’m good with not using the projectGenerator and manually specifying include/search/linker settings which isn’t a big deal with the Xcode project, but getting the make system to a point that it’ll be happy seems to be more of a challenge. Ideally, we’d use addons.make since it has all the machinery to exclude compilation of examples as well as all the custom settings the addon has defined in (weird that the project uses a .make but here it is .mk no?). Unfortunately addons.make doesn’t seem to allow references to files out of $(OF_PATH)/addons - I’ve tried ./addons/ofxMUZZY and simply addons/ofxMUZZY and in both cases make says: The following unknown addons will be ignored.

I’ve since tweaked my project’s config.make to exclude the necessary directories, but this definitely isn’t scalable as other addons will certainly have more specific needs. Is there a good way to accomplish this, maybe the syntax I’m trying to use isn’t valid? In case it matters, I’m on OS X 10.9.3 / Xcode 5.1 / oF master HEAD but am targeting the Raspberry Pi as well, hence the make need :smile:

How do others encapsulate their projects? I remember @memo had a thread on the discussion list a while back about project structures, but I don’t recall if that dove into make.

I am not sure if I understood, but you could try to set the PROJECT_EXTERNAL_SOURCE_PATHS variable in the config.make file (for oF 0.8.0)
Something like this = $(YOURADDONDIR)/addons/ofxOpenNI/include/ and so on.

Yeah, one can definitely manually add the addon to their makefile - in my case the addon folder is within my project root, so the existing make machinery auto-magicaly adds all the includes and source, but I do have to exclude all of the addon example projects from building.

What I’m hoping to do is employ the existing addon handling make machinery that is usually spurred into action via a project’s addons.make. That way each of the addon’s would be used in addition to the base addon handling (ignore examples), otherwise all the settings there will need to be duplicated when manually added.

I also filed this as GitHub issue #2892.

Trying to achieve same thing as @pizthewiz, I do not understand how to fix that.

My root project lives in ~/Docs/Dev/package/my_app and I have done like @pizthewiz with addons in the same directory (that can be downloaded directly with the project as it is tracked by Git and addons are Git submodules).

Putting everything in OF_ROOT/addons in quiet a pain for my project team. I am sure that you have already solved this issue, isn’t it ?

I reply to myself, because I find the way to achieve what I meant.

Here is what I would have found on the forum (and now it is there) that is a good architecture and configuration:


I want to spread my project correctly and simplify the way my collaborators get a copy of the project.
Though, I want my addons to be setup as Git Submodules lying in the addons root subdirectory of my project.
And finally, I want my project to compile as easy as possible without changing or configuring so much things.


/some/where/in/the/file/system/my_project ├── addons │ ├── ofxAnimatable │ ├── ofxOsc (my own flavour) │ └── ofxOscRouter ├── addons.make ├── config.make ├── LICENSE ├── Makefile ├── └── src ├── main.cpp ├── ofApp.h └── ofApp.cpp

Git submoduling:

$ cd /some/where/in/the/file/system/my_project $ mkdir addons $ git submodule add addons/ofxOscRouter $ git submodule add addons/ofxAnimatable


File addons.make

DO NOT LOAD any of your locally saved addons, but just what you need from the official $(OF_ROOT)/addons/

File config.make

Add to your file PROJECT_EXCLUSIONS += $(PROJECT_ROOT)/addons/ofxAnimatable/example PROJECT_EXCLUSIONS += $(PROJECT_ROOT)/addons/ofxOscRouter/example/src

The configuration of the PROJECT_EXCLUSIONS Makefile variable in config.make is mandatory to exclude the examples files, specially the main.cpp (or whatever is a duplicate code content) that conflicts with your own main.cpp during linkage ; of course, several main() entry point are declared in several files and the linker do not know what is the good one to use.