Since the “jucequake” that lead to JUCE 2.0 I have been very happy of the new source code structure while being a little skeptic in regards to the Introjucer tool.
I thought that this could be because of it being a new tool to get used to, so I took some time before speaking my thoughts, to see if with use they were being proved wrong.
Some time has passed, and I feel compelled to express my opinion, in the hope that it will represent some constructive criticism.
Making long story short, what I think is this: Introjucer is a very good tool to make the initial setup of a new project that needs to be created from scratch, while it falls short of the goal of being an usable tool to mantain your cross-platform project as soon as it gets non trivial.
In my opinion, the reasons for this are a couple:
(just to make things clear, I am developing desktop application on Xcode and Visual Studio, with Xcode being the platform where I do most of the development, that gets then ported to Windows. If I speak of Xcode later on, it applies with proper analogy to Visual Studio as well)
If you change some settings in your Xcode project, the next time you want to use Introjucer such change gets overridden by Introjucer re-creating the Xcode project from scratch. The only way for a change in the settings to survive the Introjucer management, is to have the change made in Introjucer itself. But not all the compiler settings are available in Introjucer. Sure they can be added, but it may not be pratical/doable in reasonable time, and this leads to point 2
By its own nature, Introjucer is a tool that is bound to be always “a step behind” with respect to the development IDEs that it wants to mimic (or, better, towards which it wants to be a common denominator). If we want a new configuration setting (let’s say, a new compiler warning flag) to be handled non-destructively in our project with Introjucer, we need it to be added to the settings that Introjucer itselfs uses to create the Xcode/Visual Studio projects. This translates in a request that is made here on the forum to jules, which currently (and very understandably) has more important things to do on his ToDo list.
In my opinion, a better approach towards this would instead involve generating proper xcconfig files for Xcode and vsprops (Property Sheets) for Visual Studio: both are essentially text files that can contain a subset of the configuration settings needed to the project. They can then be combined in various ways to provide the final settings used in compilation, leaving room for developers to customize their settings