Xcode example projects

#1

Sorry, still behind the curve in Xcode, but I’m running into oddities that seemed trivial in Codewarrior.

One is ‘dependancies’. It seems that jucedemo, jucer and the sample project should have the juce library as a ‘direct dependancy’.

Another was the xconfig file, which apparently is only read when the project opens. God Bless. When it feels like it.

But the stumbler for me is when I’ve copied the sample app to another directory, and now, even with juce.h included, it can’t find the included files, i.e #include "src/juce_core/basics/juce_StandardHeader.h"
I have a source tree, but that seems to be a sop to ex-CW people, and not really apply. I found and tried User Header Search paths with my source tree, but struggled until I removed all the white space from the path.

After that, it couldn’t find the juce project or xconfoxconfig again, and after fixing that, it can’t find the libjucedebug.a, apparently because of a path thing (/usr/bin/ld: warning -L: directory name (…/…/…/juce/bin) does not exist)

Should I give up on putting my project files where I want? Is that just not an XCode thing?

Bruce

#2

OK, sort of an update - something that I did forced the juce library project to need a rebuild. After that, things are a bit better.

If I manually apply the config flags, so my app matches the lib, then it will link. It still squawks about a path, but fleetingly, then builds and runs (although why the xconfig doesn’t work is weird (and it’s not in the xcode help at all)).

When I do run, the hello world app won’t quit (close button not active) and doesn’t appear in the dock etc. Is that just a case of the example being a bit behind?

I’d appreciate if someone has a 1.38 project they could share that can live in a user path?

Thanks,

Bruce Wheaton

#3

Seems strange that you’re having all these problems - must be something you’re doing, as I’ve never had anything like this happen.

The fact that you say it fails on #include “src/juce_core/ etc” is a bit suspicious - that’s in juce.h, and it’s a relative path, so you’ve not tried to move the juce.h file out of its tree, have you? Or have you got another stray copy of juce.h somewhere that it’s picking up by mistake? Can’t think of any other way it’d fail to find a relative path.

You can put your own project files anywhere you want - all you should have to do is tell it the path where it can find juce.h and where to find the libjuce binaries. Obviously in the demo projects these are relative paths so it’ll work on anyone’s machine, but if you move them you just have to change them to be absolute paths.

#4

Probably. It does compile now enough Xcode restarts), and seems to run. When building, there’s a warning, and if I ‘catch’ it by pausing the build I can see:

Ld "/Users/brucewheaton/Documents/Projects/Valance/Valance Project v0.1d/build/Valance_application.build/Debug/valance.build/Objects-normal/ppc/valance" normal ppc cd "/Users/brucewheaton/Documents/Projects/Valance/Valance Project v0.1d" setenv MACOSX_DEPLOYMENT_TARGET 10.2 setenv NEXT_ROOT /Developer/SDKs/MacOSX10.2.8.sdk /usr/bin/g++-3.3 -o /Users/brucewheaton/Documents/Projects/Valance/Valance\ Project\ v0.1d/build/Valance_application.build/Debug/valance.build/Objects-normal/ppc/valance -L/Users/brucewheaton/Documents/Projects/Valance/Valance\ Project\ v0.1d/build/Debug -L../../../juce/bin -L/Developer/SDKs/MacOSX10.2.8.sdk/usr/lib/gcc/darwin/3.3 -F/Users/brucewheaton/Documents/Projects/Valance/Valance\ Project\ v0.1d/build/Debug -filelist /Users/brucewheaton/Documents/Projects/Valance/Valance\ Project\ v0.1d/build/Valance_application.build/Debug/valance.build/Objects-normal/ppc/valance.LinkFileList /Juce_Folder/juce/bin/libjucedebug.a -framework Carbon -framework CoreAudio -framework AGL -framework QuickTime -framework CoreMIDI -arch ppc -Wl,-Y,1455 -mmacosx-version-min=10.2 -Wl,-syslibroot,/Developer/SDKs/MacOSX10.2.8.sdk

The key part obviously being:

But I don’t see anything that has that path. I suppose the juce lib does, but it’s in via the project, so shouldn’t it know?

Anyway, I restarted with a copy of Jucer, and it’s still a lot of hassle, but getting there, including working close button (with the sample main.cpp). Perhaps you could make the example project more portable? Maybe with a Juce Source Tree that it references?

Thanks.

#5

If you think you need to restart xcode, that’s probably because there’s something you’re not understanding… I don’t remember ever having to restart it to get it to work properly.

The path is relative because the juce project that’s in the “external projects and frameworks” is set to use a relative path. Just change it to use an absolute path if you need to. Or explicitly link to the juce library with a linker option instead of putting it into the xcode list of files (that’s what I do with the demo project and jucer)

#6

I worked those out. There was still a hidden reference relative to the juce folder somewhere. I’v since found that the settings in the targets info doesn’t always 100% match the main app settings i.e. there’s about four places the path could be. But I still couldn’t find it.

With a copy of Jucer (plus what I’d learned thrashing about), I’ve been able to get to where I need. I did have to create a new target and manually copy setting from the older across to get a product not called Jucer.

So I good to go from here, thanks for the pointers. I would still ask that the ‘starter’ project be more portable, so we can copy it out and work right away. It would be easier to change the Juce path once than working out which paths are relative and need to be modified.

Bruce

#7