My project is an iOS app which uses Apples SDK for the UI but uses Juce for almost everything else. How would I go about adding the new modularized Juce to the existing project?
The Introducer creates a deeply nested folder structure with many files that I would need to replicate manually in my existing project? Is there an easier way?
Patrick
The complete file structure shouldn’t be that hard. XCode lets you ‘Create groups for any added folders’.
I would use Introjucer to build a placeholder project that uses all the modules that you are interested in. Be sure to use the copy to the project option.
Then remove the Amalgamated or lib from your existing project.
Next add two folders, “Juce Modules” and “Juce Library Code” to your project from the dummy project. I’d copy the folders manually then use add so that you can preserve both file hierarchy and get folder groups in your project.
Last, update all your juce.h includes in your code to use “…/JuceLibraryCode/JuceHeader.h” (or whatever the path should be).
I just tried this to add Juce (modules) to a non-Juce iOS project and it seemed to work just fine.
Can’t this also be done by just opening the static library project and Command-dragging the source folders to the destination project?
I added the juce modules tby opening the static library project and dragging the Juce Library Code folder to my project. Because the Juce Modules folder is missing in my project I left the static library project in the Xcode workspace to enable debugging.
Thanks for the help!
Patrick
[quote=“TheVinn”]
Can’t this also be done by just opening the static library project and Command-dragging the source folders to the destination project?[/quote]
Sure. I just found it handy to see the intended file structure and have a working test bed (in case expected compile settings have chnaged, etc.) Also, the tool does a reasonable job of tracking module dependancies and letting you set configuration. The later bit me when I switched to modules, because the default configuration had changed.
[quote=“jfitzpat”]The complete file structure shouldn’t be that hard. XCode lets you ‘Create groups for any added folders’.
Next add two folders, “Juce Modules” and “Juce Library Code” to your project from the dummy project. I’d copy the folders manually then use add so that you can preserve both file hierarchy and get folder groups in your project.[/quote]
Wouldn’t the created hierarchy contain cpp files that Xcode would compile?
Patrick
I’m not sure I understand the question. When I moved to modules I had previously been using Amalgamated. I like having the used source in my project because I can then tag it in Git and have a reproducable version. If I use a static lib, I can check in the lib, but it is awfully nice to have all the source exactly as you released (yes, you can do sub projects, etc., I just find this clean and clear).
It wasn’t immediately clear to me how Jule’s intended the files to be organized, so using the Introjucer gave me a good look. It also helped me setup all the configuration options. I then moved the generated folders as is into my existing project. Another thing I found helpful was Introjucer knowing the dependancies. On the mobile platforms, the total JUCE library is getting pretty big. Especially since you can end up with multiple copies in your executable (ex. to support older iOS deployment targets you need to build using two different archs, similiarly, you can end up with two or three different builds in an Android package). The ability to go lighter weight with modules did end up cutting compiled code size (which has me wondering about the compilers, but that is another subject).
You can definitely setup modules without Introjucer. When I first looked at Android, 4.0x was not working correctly. It turned out to be OS changes, but it initiallly had me looking at building. I ended up setting up that building from scratch. It was a pain, but doable.
Vinn has some strong opinions about modules organization, the Introjucer, etc. but I haven’t followed those discussions closely enough to have an opinion either way on his specific points. For me, modules is a lot easier than amalgamation. And now that the Introjucer automates all the crud I was doing by hand for Android (where you have to change even your folder heirarchy to reflect your app name), I’m pretty much in the ‘All Hail the Introjucer!’ crowd too.
But, again, it isn’t absolutely necessary and I can’t really comment on Vinn’s specific issues.
No need to choose one or the other. You can have both! My latest iteration of producing amalgamated Juce sources creates a separate, single amalgamated .cpp for each module:
http://code.google.com/p/dspfilterscpp/source/browse/#git%2Fshared%2FJuceAmalgam
[quote=“P4tr3ck”][quote=“jfitzpat”]The complete file structure shouldn’t be that hard. XCode lets you ‘Create groups for any added folders’.
Next add two folders, “Juce Modules” and “Juce Library Code” to your project from the dummy project. I’d copy the folders manually then use add so that you can preserve both file hierarchy and get folder groups in your project.[/quote]
Wouldn’t the created hierarchy contain cpp files that Xcode would compile?
Patrick[/quote]
I took a another look at the “Add files to…” dialog in Xcode that is used to add the modules subfolders. I missed the checkbox to set the target ownership in that dialog. If I remove the target ownership checkmark the added cpp files are not part of the target and will not be compiled by Xcode. This is exactly how projects generated with the Introjucer contain the modules folder.
Patrick
