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
addon_config.mk (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
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
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
addon_config.mk 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 ├── README.md └── src ├── main.cpp ├── ofApp.h └── ofApp.cpp
$ cd /some/where/in/the/file/system/my_project $ mkdir addons $ git submodule add https://github.com/groolot/ofxOscRouter.git addons/ofxOscRouter $ git submodule add https://github.com/groolot/ofxOscRouter.git addons/ofxAnimatable
DO NOT LOAD any of your locally saved addons, but just what you need from the official
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.