Please excuse the rewarming of this topic…
I’d like to make a case for keeping the static library projects for Windows, and for reviving them for MacOS.
We use the buildbot method in our development to create binaries for other developers and testers. For a number of reasons the servers always build from fresh checkouts - but using prebuilt Juce libraries. There may be others out there who do the same, and are fervidly hoping for this as well??
** We have a regular plethora of Juce apps in our source trees. Building the Juce sources for each app and variant on each commit will make the build times close to unworkable for us, even though our build machines are mighty beasties.
We fully understand that it isn’t possible to provide a static library project (especially for XCode) that has the proper defaults for everyone’s purposes, but they’ve always been an extremely useful starting point. Perhaps you could include an #error directive in a project header file, with a caveat saying that “A library project can’t anticipate all appropriate build settings. Not intended to be turn-key, so no nastygrams on the forums please.” ??
If the static library projects disappear, we would look into maintaining them separately of course.
I was glad to find a Juce 2.0-related project in git for MacOS (removed before the release), and used that as a starting point to get updated to Juce 2.0, and it saved a lot of development time.
** If there is a great deal of code reorganizing in the future we’d not have that advantage again.
There are a couple of other key reasons we like the static lib projects. If you’re open to the idea I can elaborate a bit more.
I’ve seen that response before in the forums, so I’ve looked at the IntroJucer app before posting, and I’m not seeing how to get it to produce a library binary.
I created a new project with static library linkage, hoping it would create a library subproject or something that would result in a library binary, but the resulting project fails to link since it doesn’t create the lib… I’ve also tried creating a Static Library project type, thinking that was the route, but it results in an empty project, as the Juce Linkage Method is forced to “Not linked to Juce”
The GUI seems self explanatory, but I’m missing the method here for making a static lib.
Can you link me to documentation or discussion about this?
I use premake to generate cross-platform Makefiles (mingw32 for Windows).
There’s not much I can say, you really need to take a look at it to understand how it’s working.
But I think I do exactly what you want to - build static libs out of juce modules first, then build plugins static-linked to those libs.
EDIT:
Note that it’s is a linux related project. I’ve sucessfully build win32 binaries but haven’t tried Mac OS ones yet, so my guess is that^ sources are broken for mac. It will still give you an idea on how to do this though.
My other reason for this is that we have customers (Juce licensees where appropriate of course) that use our Juce-oriented sources. Before we just told them to download Juce and use the included projects to build the lib’s. Since our sources use static Juce linkage, it would be desirable to tell them “Use IntroJucer to build the libraries, using release x.y” in the future.
If the Builds directory is deprecated, any thoughts on a handy IntroJucer feature that creates Juce library projects?
Could work. Use a common platform intermediate files path. Include all modules in all apps, and don’t touch module files along the way. For fresh XCode installs, make sure the User knows they have to set the XCode preference that allows projects to override the derived intermediate files locations and let the projects control it. I have a sneaking suspicion that there are some snags to this method, but worth a try in the interim.
You may want to split build by types (ie, Standalones vs Plugin).
In linux, the standalones need to link against ALSA libs to work with MIDI, but that is not needed (and undesirable) for plugin binaries.
afaik, Mac is the same - CoreMidi is only needed in the standalones.
BTW - am super glad to see that IntroJucer adds file references with relative paths, and frameworks relative to SDKROOT, though not surprised that Jules does things the right way as per usual.
This means no need for artisanal hand-editing of the project files to get rid of absolute paths for both build-server and local use.
