Introjucer criticism

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)

  1. 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

  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

While I agree with you, you don’t really have to use the introjucer do you ?
Personally, I use the intro jucer when I have to create a small project quickly for rapid prototyping, for what it does it’s job.
For my bigger project, which started before the introjucer, I used, and still use premake4, which is amazing.

I just hope that we we will never have, somehow, to use the introjucer in a mandatory way …

If you’re doing cross-platform work, using the IntroJucer after the initial phase is helpful. The problem is that you work in your primary platform, and add some files, remove some, rename some, keep rolling, and when you come back to other platforms they are way out of sync. Then you go to the IJ project, and work it out, which requires a few iterations of - add files, go to Xcode, reset any other settings, try it, back to IJ, change the other few things, back to Xcode, change the project, etc.

But - if you can embrace IJ and try to use it’s settings, and try to avoid using others - which is a bit wonky, in that you end up with worse xcode projects (no sub projects, libraries added via command line not in the GUI, etc.), it’s ‘usable’.

[quote=“dinaiz”]While I agree with you, you don’t really have to use the introjucer do you ?
Personally, I use the intro jucer when I have to create a small project quickly for rapid prototyping, for what it does it’s job.[/quote]

I used it as well to “bootstrap” multi-platform projects, but that’s my point: if that’s its only use, a template project (which is what you get when from Introjucer) would work equally well, and if sharing IDE/compiler settings among such projects is desirable (and I bet it is), that’s where xcconfig or property sheet files come handy: jules could store them in JUCE and have all the template projects inherit those settings.

Writing a wannabe IDE just to generate projects with those settings injected seems too much of an effort to me, provided that, as I said before, its limitations are clear:

frankly, it’s 2012 and I can’t think of a reason for which I should stick with such a tricky workflow when modern IDEs already provide the tools for you to “script” and “reuse” almost everything

If you have a project that’s running on 5 platforms, with 5 different IDEs, then it doesn’t matter how great those IDEs are, your big problem is that keeping all those projects in sync is a nightmare. That’s the problem that I wrote the introjucer to solve, and in my own work I couldn’t live without it now.

Maybe you’re only targeting one or two OSes so for you it’s not such a big deal. But for me, when I hit something that the introjucer doesn’t support, it’s almost always much easier to add that feature to the introjucer than to go off-piste and start changing settings in the IDE itself.

Another bonus is it avoids the need to continually maintain your projects for compatibility with the latest IDEs and OSes. Last week I had to dig-out an old project that I last built a couple of years ago and get it running again. I just re-saved it with the latest version of the introjucer, and all the old Xcode3 and VS2008 projects magically turned into nice new Xcode 4 and VS2010 projects, with all the latest settings and fixes. No need for me to manually go through and check all the hundreds of obscure settings that might have needed an update.

Maybe one solution would be to provide a kind of feedback, allowing the IntroJucer to update some of the IntroJucer project parameters, according to the changes done in the different IDEs ?

Yeah that would be great. Perhaps a Visual Studio addon which rebuilds the .jucer file when the .vcxproj is changed?

Hmm, this sounds like a nightmare to maintain as well, it would require extra carefullness in order to guarantee that the jucer projects that gets generated by such addon does generate the same vcproj when exported to Visual Studio from Introjucer… in other words, Introjucer and this addon should be kept one the perfect inverse funcion of the other. Kinda complicated, or am I missing something?

Yes, it is quite complicated and would require significant maintenance. But if we can dream about previewing GUI code changes on the fly, can’t we also dream about working in our native IDE and still being able to produce IDE-specific project files for all platforms?