Juce 2.0 - Building static library


I just downloaded the recently released 2.0 version and, to my surprise, the “Builds” folder is gone!
So… looked in the extras folder and found a “static library” directory, yet it doesn’t have OS X project files. It does have a jucer file, which I opened, added Xcode an d iOS projects and saved… the projects were Empty :-(.
I looked in the docs, but didn’t find much info (other than saying to “add the project” as a subproject in Xcode, yet there is no project…

I’m sure I’m missing something really obvious, but how are we supposed to build a static library with the new “Modular JUCE”?

Thanks for your help,



Good question. Truth be told, you don’t need the static library in order to use Juce. Just add the corresponding module .cpp into your existing application project. For example, juce_core.cpp. I believe this is superior than linking with a static library, and the model which I have switched to for my own internal development.

The problem comes when you want to debug and have convenient access to the files, or when you want to do a search through all files (the IDE won’t know about the actual sources).



The static library project is just in there for old windows users who’d have moaned if I’d removed it… (Though I will remove it anyway before long). Since the situation with libraries is even more complicated on OSX I decided not to even attempt to support static linkage there.

Definitely the easiest, fastest, most versatile way to use the library is like Vinnie says: stick the code directly into your application. That concept isn’t new to this 2.0 release, I’ve been recommending that approach for at least a couple of years now.


Uhh…if you take away the static library project then how would one set a breakpoint or do a Find in Files ?


Eh? The same way you’d set a breakpoint or search in any other source files (?)


Eh? The same way you’d set a breakpoint or search in any other source files (?)[/quote]

I set a break point by expanding groups in the project file containing the JUCE sources, locating the desired file, double clicking to open it, placing the cursor on the line of interest and then choosing the Set Breakpoint option. Of course, this requires that the JUCE sources are actually in a project in the current solution (Visual Studio).

With the modules, you don’t add all the JUCE sources. You add something like juce_gui_basics.cpp instead. But what if I want to set a breakpoint in juce_Component.cpp? The only thing I can figure is that I have to have an explorer window up somewhere, switch to it, and use it to open the file. Which truly sucks. Or maybe I’m missing something? Please, if you know a better way, I would love to hear it.

Now when I do a Find in Files I usually choose “Current Project” or “Entire Solution”. This instructs the IDE to look in all files that are known in the current project, or all projects in the solution. Again, we have the same problem. If I’m looking for all calls in the JUCE source code to setVisible, and I only have the module .cpp files (juce_core.cpp, juce_audio_basics.cpp, etc…) then Find in Files wil not locate it.

Besides breakpoints, there is also the problem of browsing the JUCE sources in general. It is very often the case that I want to see which classes are available, open up a header file corresponding to a class, and just browse the interface. How do you do that with just the library code files (juce_core.cpp, etc…) ?

I brought these issues up a while back, and your consensus was that the static library project had to stay. Now you’re suggesting, to take it away? How will these issues get resolved?


If you use the introjucer, it adds all the module’s files to the project for you. That’s how I’ve been working, quite happily, for the last 6 months. (I thought you knew about how that worked…)


I was not aware that IntroJucer also added the individual source files as well as the module files, no. I thought we had decided that IntroJucer would not be required? Now it seems, that IntroJucer is required (unless you want to manually apply all changes to the JUCE source tree with each revision, which is not really an option).

Here’s a better idea - why don’t just make a few of the tweaks I suggested for IntroJucer to let it more use-cases, and keep the static library projects around in the official distribution instead?


Thanks both Jules and TheVinn for the responses. It’s true that, at least in my case, static linking to JUCE is not mandatory and there should be no issues if I simply include the required files.