Well, check this out:
So, this ambiguous statement can be interpreted two ways. These images should make it clear:
(1) Case ONE: Juce modules only, added directly to project:
[attachment=1]JuceCode1.png[/attachment]
(2) Case TWO: Juce modules plus original sources, added directly to project:
[attachment=0]JuceCode2.png[/attachment]
So, its pretty clear that for case one, locating a file to set a breakpoint is going to be a pain in the ass. You would need to either use the Windows Explorer to locate the source file in question, or navigate your way to it using File->Open… and then picking through the Open common dialog. Furthermore, find in files would no longer work.
For case two, things are much easier for debugging. There is no problem whatsoever, just open the appropriate file and set your breakpoint. Additionally, it is easier to open up a header to inspect an interface if you want to look at a particular class to find out what’s available.
However, for case two, we have a new problem: when time a file is added, removed, renamed, or moved in the latest tip, EVERY project which has the Juce sources added to it needs to be updated manually! Holy smokes, that sucks!
At this point, the trend is to cry “USE INTROJUCER” which “automates the inclusion of Juce sources” blah blah blah. But this is not an option for me, and many other people. For this reason, we have three alternatives:
-
Use the amalgamated form of Juce. For this to be effective, Jules needs to keep the amalgamation up to date, or else it will always be a little bit behind in terms of compile errors and functionality. Whoever maintains the amalgamation will always be trying to play “catch up” to changes in the tip. For this reason, I feel official support for the amalgamation should be maintained instead of dropped.
-
Use the static library juce project located in extras. It would be ideal if we could keep official support for these projects instead of dropping them, for the same reasons as keeping support for the amalgamation. Because Jules is always the “first to know” about changes in the source tree, it is logical for him to migrate those changes to the static library. If Jules keeps a test application that links against the static library project, resolution of problems with that project will be swift. Besides, if IntroJucer has so many fancy code maintenance features, shouldn’t it be possible to automate the generation of the static library projects in extras using the IntroJucer itself?
-
Use a custom static library project (which has to be manually maintained, but can be shared among multiple projects). This has been my personal solution to date. Although this requires additional effort, it is made much simpler if the static library projects are kept up to date (because one can start with that project and re-apply custom settings via property sheets).
When I speak of “lost functionality”, it is these three use-cases that I refer to. If we drop official support for the amalgamation and/or the static library project, it is true that they might continue to work for a little while - but eventually the Juce source code will diverge enough to permanently break those two features.
To summarize my position, I feel that moving to mandatory usage of IntroJucer is a mistake, and that the marginal amount of additional effort required to keep official support for the amalgamation and static library projects is worth the benefits.