Introjucer and relative paths in XCode

I’m trying to use the Introjucer and the generated project has failed linking.

It failed as it was searching for “libPluginLibrary” at “$(SRCROOT)/…/…/PT_80_SDK/MacBag/Libs/Release”,
but it didn’t know what SRCROOT was. (so it looked for it at Builds/MacOSX/…/…/PT_80_SDK etc)


s.add("SRCROOT = \"../..\"");

at XCodeProjectExporter::getTargetSettings
solves the problem.

This report is based on juce version from git with last commit from 2012.02.17 - b66a82aa441ddd80f61d5b8049d6e3a35ebddb1b

btw, is this the proper way to report bugs etc or is there a different preferred way?


Thanks, I’ll add something to handle that!

And yes, the forum’s the place for bugs and requests. I’ve never been a fan of formal bug-tracking software, (though I’m sure bug-trackers are a lot nicer to use than the last time I used one, many years ago!)


I don’t know if this has changed in the latest versions of xcode, but this is definitely NOT right:
If you do not define SRCROOT it is defined per default by XCode to point to the ABSOLUTE path of the folder containing the project files.

Defining it as a relative path is a very bad idea:
Depending on the build settings your products or DerivedData can be in a completely different place. The only way to get some kind of “absolute” reference in your fifle system is by using SRCROOT, all the rest is relative defined to that one.

I opened an introjucer project in xcode (4.3), deleted the SRCROOT define that the introjucer created and now SRCROOT (as if by magic) refers again to the absolute path of the project file.

s.add(“SRCROOT = “…/…””); --> Could this line please be removed again from the introjucer?

  • Bram

Hmm… I don’t think I’d have added that if it wasn’t needed… Perhaps it’s something that Xcode 3 didn’t do. But thanks, I’ll take a look at that.

Thanks… Most of my problems can ALSO be solved by a post-build script that copies libraries to where they need to be in the app bundle, so that would be fine too…

  • bram