Crippled on Xcode


#1

Where’s the static library project for Xcode? How am I supposed to browse the Juce source tree in Xcode without using IntroJucer?


#2

Please don’t start this rant again vinnie… If you just want to browse the code, open up any of the demo projects, or make your own dummy project with the introjucer, and all the files are right there for browsing.


#3

I’m not really a big fan of the introjucer, but Jules is right in this regard. You can get the whole module by simply adding one file (like juce_core.mm). I made my own little wrapper files for each of those in my source tree, so it’s a fairly trivial matter to include them. My hacked AppConfig.h defines a few things and then includes JucePluginCharacteristics.h (Jules probably shivered when he read that), but it works fine and I don’t have to pay any more attention to it.


#4

The problem was not adding the module .mm files (which was easy, I just expanded the modules tree in Finder and created a multiple-selection before dragging into Xcode). It is that there is no static library project for Xcode (and Jules explained that he plans on removing it for Visual Studio).

The sources I’m talking about are the actual source files, like juce_Component.cpp not the module sources (i.e. juce_gui_basics.cpp). There’s no convenient way to browse them.

The work-around that Jules provided is a step in the right direction. But unless Jules plans on running Introjucer for every “extras” project to recreate all IDE project files, then every time he adds, moves, or renames a JUCE source file those generated projects will go out of date.

At this point Jules or someone else will chime in “Just use Introjucer”. Which I find incredibly annoying because what used to take one step (git pull) now takes several. I really dont feel like running Introjucer just to bring a dummy project used to browse the Juce sources up to date, every time I pull from the repo.

Why is it so hard to include the static library projects? With all the work that went into Introjucer (which is GREAT for some things, just not this one) I find it baffling that we can’t have up to date static library projects in the JUCE repository.

I brought this up all throughout the discussions taking place while Introjucer and the new modules system was being hammered out…and now I am really frustrated because it is affecting me. The work-around of including the JUCE demo in my workspace so I can set breakpoints and look things up is alright for now, but could stop working any time (if Introjucer is not used to renegerate the JUCE source tree inserted into the IDE project file before JUCE sources are committed to the repository).


#5

Personally I don’t use the static library project anymore but I don’t see why it can’t continue to be supported & kept up to date. Maybe we could come up with some script that automatically adds new files to the static library Introjucer project and then re-generates the platform projects. Jules could then include this in his commit chain so he wouldn’t have to deal with it directly. Not sure how feasible this is though but could be an option.

I also don’t really understand the problem when using Xcode. Doesn’t ‘Jump to definition’ (cmd+double click) work for you even without the individual sources present? I often just type a class or method name so I can quickly jump to its documentation. You can then use ‘switch to counterpart’ to view the h/cpp/mm file or use the quite handy assistant editor to view both at the same time. I find this is quicker than manually browsing a source tree. But, if you really want to browse the tree whats wrong with leaving a Finder window open with the source tree in and navigating that? Or typing a file name in Spotlight?

I may be wrong here but I get the impression your frustation is more due to a lack of experience with Xcode than the way Jules manages the library these days. I know I feel something similar when I switch to VS so spend as little time as possible in the IDE.


#6

Pretty unrelated, but can anyone tell me the difference between AppConfig.h and JucePluginCharacteristics.h? It looks like the IntroJucer didn’t create a JucePluginCharacteristics.h file, but much (if not all) of the same #define’s are in AppConfig.h. Just wondering if I should create it myself, or do something in the IntroJucer, or not worry about it at all!

Thanks a bunch.


#7

Yeh, thats a legacy thing, all the required info is in the AppConfig file generated by the Introjucer. You should be able to generate->build->go.
If you’re using VST you’ll need to add the VST folder in the project exporter in the Introjucer. For AU’s follow the steps here.


#8

This is not an option, because then every time JUCE adds, renames, or removes files, everyone who wants a static library project in Xcode would have to regenerate it using IntroJucer. It makes so much more sense for Jules to do this himself and include it in “extras/static library”. This way anyone who pulls the tip of the master branch will always have an up to date and properly synced static library project.

Can we please fix this? There’s currently no workflow for me on Xcode that doesn’t require constantly regenerating a dummy project. Jules, this is as easy as adding a few lines to a script which can be run periodically.