why are Xcode projects addons paths relative to the project instead of OF_PATH?

[artificiel]

why a location-dependent

../../../../../home/source/openFrameworks/addons/ofxX/src

instead of

$(OF_PATH)/addons/ofxX/src

[dimitre]

Yes I think we should go for the second. what is needed? changing the template or projectGenerator too?

[artificiel]

ah indeed it seems to be PG that constructs those links -- but i'm not sure i've never looked at the PG code (i have a bit of an Electron problem...). it seems limited to the addon paths; the core OF stuff is OF_PATH based.

[edit: but maybe there is a (perhaps historical) reason for that behaviour? that was may question as such]

[dimitre]

I can take a look on this later. the good thing it is not Electron based (some allergy to this one). it actually invokes the commandLine under the hood.
if there is a reason behind this I can only guess.
But I know OF didn't work 100% if you set a path different than ../../..
not sure if it is already fixed but I just stick to this path

[ofZach]

just a note that the paths in an OF project are generally always relative, but not location dependent

Ie, I don't think you see this unless you make a project outside of the OF folder

../../../../../home/source/openFrameworks/addons/ofxX/src

but more relative to the root of OF -- ie, like this:

I am honestly not so familiar with how it might work with $(OF_PATH) -- but the idea was to make it easy to move OF, and also to make it easy for you to share projects. You just need to think about the relative path to the root of OF for where the project is located.

I think we want to avoid something where projects break the movement you move the OF folder or that projects break when you move machines or share projects with someone else.

[ofZach]

ah I see! that makes sense then....

[artificiel]

(sorry did something strange by including the image and the previous post was posted) so:

the path is relative to the project. similar thing is set in QtCreator .qbs here we see my project is outside OF, and in a somewhat deep hierarchy:

in the project settings, if we look at library includes, they are configured by OF_PATH: (so, Xcode presents them as the "result" path, but editing it reveals it's based on OF_PATH

whereas the addons include are "hard coded" (no variable)

so it means that to move a project requires a PG pass to re-write all those. the idea is to have them reference OF_PATH so a project could be pointed at a different OF root simply by editing the .xcconfig (QtCreator does that re-parses the paths when you edit the .qbs)

[artificiel]

ha you're too fast our messages cross but anyhow more info provided!

[artificiel]

perhaps there is an argument to force a PG re-write to confirm the addons are present, but I think it's not always ideal, as some projects Xcode settings might have been tweaked.

[ofTheo]

Here is some of the relevant code:

https://github.com/openframeworks/projectGenerator/blob/master/ofxProjectGenerator/src/projects/xcodeProject.cpp#L129-L144

I think it should be doable to get working, but the PG is a bit of a beast.

I don't think it would involve electron though, it would be mostly in the command line app: https://github.com/openframeworks/projectGenerator/tree/master/commandLine

If someone wanted to take a stab at it, they'd be totally welcome to! 🙂👍

[artificiel]

is there an authoritative guide on how to get PG to build? most docs (including INSTALL_FROM_GITHUB.md) mostly say "ah... hm, yeah, don't bother and grab one from a release".

i'm a bit confused about the hierarchy -- trying to build within the OF root seems to trigger a russia-doll download of OF; trying to treat the project commandLine as an OF project and run it in PG gives a "local addon" error. trying the instructions here fail at ./scripts/osx/buildPG.sh and gives: fatal: destination path 'openFrameworks' already exists and is not an empty directory.

(as i understand things: in order to perform the above tweaks i do not need the GUI version, but i still need to build the commandline).

[dimitre]

I'll share what is working for me. I've made a fork of project generator and cloned it inside apps folder. So it is the needed directory depth to make it run well.
so inside OF strucutre it is something like this
apps/pgd/commandLine

I can recompile commandLine which is enough to test this kinds of things because you can invoke it directly from command line,

cd $ofw/apps/werkApps/Proto; ../../../apps/pgd/commandLine/bin/projectGenerator.app/Contents/MacOS/projectGenerator -o"../../../" -t"vscode"  .
open *.xcodeproj

[artificiel]

OK that works!

[artificiel]

so, as far as Xcode/macOS goes, the core libs are defined in the OF tree with the $OF_PATH variable, ex glm:

openFrameworks/libs/openFrameworksCompiled/project/osx/CoreOF.xcconfig

Line 23 in 61a045c

HEADER_GLM = "$(OF_PATH)/libs/glm/include"

these libs path populate $OF_CORE_LIBS, and are pushed as "other linker flags" into the Xcode project by the project's .xcconfig which comes from the template:

openFrameworks/scripts/templates/osx/Project.xcconfig

Line 47 in 61a045c

OTHER_LDFLAGS = $(OF_CORE_LIBS) $(OF_CORE_FRAMEWORKS)

so that's more or less statically defined by the combination of the Xcode template, and the CoreOF.xcconfig and ends up as:

now the addon are treated by the commandline PG, and they are configured as per a relative path based on the project's position (slightly counter-intuitive as the addons are relative to OF, but this makes a strange ping-pong between the project source, OF itself, and then the addon directory):
https://github.com/openframeworks/projectGenerator/blob/b883ac876854ccc9a66c16075f8978dcccef40e3/ofxProjectGenerator/src/projects/baseProject.cpp#L276

changing that line 276 from addon.pathToOF = getOFRelPath(projectDir); to addon.pathToOF = "$(OF_PATH)/";

results in paths that look like this:

and suddenly, by simply editing the OF_PATH at the top of the project's .xcconfig, your project can be swapped between OF trees (or computers) without a trip to the ProjectGenerator (so, preserving all settings, etc.) without depending on that "relative depth".

my question: changing baseProject.cpp affects all platforms. is there a drawback to rely on OF_PATH on other platforms? i see the qbs template does not call baseProject::addAddon; visualstudio does -- is there a similar declaration of OF_PATH in VS (i don't have windows it's harder to explore) or should some more xcode-specific change be implemented?

[artificiel]

@dimitri can you double-check those absolute path are not "live calculated" by Xcode? for instance here the GLM paths look static/absolute, but double-clicking reveals they are variable-based.

so as i understand these paths (the LIBS, not the addons) are not calculated by PG but by the combination of project.xcconfig + CoreOF.xcconfig. PG provides the base OF_PATH (which comes from -o or PG_OF_PATH or the PG GUI -- so a user-defined intervention, except fo the bin releases GUI which are pre-configured to fit).

@theo there is also prefix_path in addons.cpp that defaults to addon.pathToOf maybe it's the real target? i will do more tests to isolate better the impact of addon.pathToOF on the internals with complicated addons like Cv, but a direct post-process substitution of $(OF_PATH) might be a good solution. that implies that OF_PATH is also provided in visual studio? (it's the only platform i can't test myself). i will test how it behaves with "additional source folders" also.

[dimitre]

Hey @artificiel those paths I'm investigating are the addon path and as you already said before they don't use OF_PATH variable, so they are hard coded as relative beginning with ../../.. here.
I suspect addon.pathToOf variable is unused but haven't investigated further.

[dimitre]

I've modified PG also to print paths, so some relative things are made absolute by the PG

[artificiel]

ah! yes that what i meant to get those addon paths to be relative to OF my proposal above is to change line 276 from addon.pathToOF = getOFRelPath(projectDir); to addon.pathToOF = "$(OF_PATH)/"; then they will be based on OF_PATH.

but as @ofTheo raises maybe it's not the right step within the PG structure there might be additional ramifications for internal processing that will not understand the variable. i can do more tests with complicated addons (will all sorts of flags) and the "additional source folders", but not immediately!

[artificiel]

the end goal is to have an "editable single entry definition" of OF_PATH in the project files from which everything related to the OF installation (including addons) derives from.