Thumbs down on new modules project

[TheVinn]

And, if you look at my dspfilters open source library, you will see that the three projects (the juce amalgamation, the dspfilters library, and the demo app) all have shared settings via XCode 4's .xcconfig files:

dspfilters_xcconfig.gif (14.85 KiB) Viewed 1863 times

dspfilters also uses property sheets for Visual Studio so you can look at that as an example, as well:

dspfilters_vsprops.gif (6.55 KiB) Viewed 1863 times

So basically you are saying use IntroJucer, a separate application and additional step in the build process, to accomplish that which can already be done using the features built-in to both development environments, because you can't be bothered to learn all the features of the IDE?

This is exactly why I want control over my project file, and why I do not want to depend on an additional tool to put my projects together. For the same reason I use C++ - I want total control over my projects so that I can optimize them fully to accomplish my goals.

Thumbs up to a better organization for Juce source files and modularized include structure, but thumbs down to requiring IntroJucer! And thumbs down to .cpp files which don't get compiled - Qt Creator IDE does not have this feature of being able to disable .cpp files from compilation but still have them show up in the IDE, so we have taken a backward step in compatibility.

[Bruce Wheaton]

I can answer that! No, I don't want to know about Visual Studio style sheets. I also don't want to know about Xcode configuration files, any more than I have to, or makefiles, or Eclipse whatevers etc.

IntroJucer is an excellent tool to start a cross-platform project. From there, I've found I have to tweak manually, but things are close enough that I can 'work it out' in most environments. I don't find going back to IntroJucer to add each file is useful, since it inevitably writes over project settings that it couldn't anticipate, but if I wanted to add a module, say, I could stomach it.

I agree, and I'm sure most do, that you shouldn't 'have' to use IntroJucer. But you seem to be insisting that you 'never' have to use it. You may be on your own there. It's a useful tool, and I think most of us are happy to use a fairly simple - the comparison to AutoTools is a stretch, IMO - tool to generate some projects occasionally.

By which I mean - you're the 1%. It's going to be harder for you to do things differently than the 99%. That's the way it is. I'm certain you can handle it - I've seen your code, and configuration stuff. Please don't get irate if your quest to get useful tools and structures removed because you don't need them fails - I think most of the rest of us like them, or at least like to have them available as examples and to make examples.

And Merry Christmas!

Bruce

[TheVinn]

Please don't get irate if your quest to get useful tools and structures removed because you don't need them fails

I'm not suggesting in any way that we abandon IntroJucer, just that it should not be required in order to build.

[gekkie100]

I'm totally agree with TheVinn here that the IJ should not become mandatory for setting up projects, and at my office here i'm not alone. So let's up that 1% a bit shall we.

[murks]

I agree as well, Introjucer shouln't be strictly required to write/configure/build a juice project.

I'm not very worried about the project file. From the small example I looked here the *.jucer file contains mostly introjucer settings and whether or not to compile a file. I guess something like that is necessary for introjucer to work with all those different platforms.

However, what worries me more is what I found from looking at the generated makefile. The file is simple enough to understand, so it could be hand-written, but there are some obscure magic numbers in it.
Examples:
"JUCER_LINUX_MAKE_7346DA2A=1"
$(OBJDIR)/MainWindow_499ac812.o

If those numbered objects and that numbered build flag are required then I would not be able to write a Makefile by hand. I don't know whether they are required and I have not the slightest idea what "JUCER_LINUX_MAKE_7346DA2A=1" does.
Well, I'll probably see soon enough whether it's still possible to build by hand when I attempt to write my Makefile by hand and/or use an established build system (waf).

[chkn]

i see the introjucer as a tool to handle cross-plattform projects. And yes, it adds another level of complexity, but why not?

Frankly speaking, I don't like having to go back to the introjucer each time I want to add something in my VisualStudio project

yes, this is stupid, but it has also positive effect, all your different project exports are synchronized.

From there, I've found I have to tweak manually

What concrete is missing, why not add this to introjucer?

[Bruce Wheaton]

From there, I've found I have to tweak manually

What concrete is missing, why not add this to introjucer?

Jules has been clear - completely parsing and then not mangling projects such as Xcode projects is not feasible. It seems unlikely to me that every single option possible in every single IDE can be accounted for, and in practice, no, they can't. For instance, an iOS project could have 6 or more variants for sim, device, deliver, profile, iPad, iPhone etc., each with a few options changed. It really doesn't make sense to pull that all back into another tool, and incur the extra penalty of working out the option, testing it in the IDE, moving it back to IJ, then back to IDE (even when it probably wouldn't affect the other platforms, so there's no gain). I also don't really care for the Juce trick of having every file included in every platform.

That would be hoping for the IJ to be the sum of all IDEs, or for us all the settle on some lowest common denominator. Those aren't reasonable compromises, IMO.

IntroJucer needs to be just that - an intro to each Juce project. Personally, the insistence of not using it all - but being willing to use other, less user friendly build systems - is odd. At least IJ has a cross-platform GUI that works. I compare this situation to Git. If a library I want has its source in Git, I use Git to get the source. Just the way it is.

Bruce

[hladik]

Probably I'm missing something, forgive me if this is the case.
When Jules adds or remove a file from JUCE (and that happens frequently), I am required to use the Introjucer to update my projects, right? And the Introjucer rewrites them from scratch, erasing my settings, right?

[jules]

Probably I'm missing something, forgive me if this is the case.
When Jules adds or remove a file from JUCE (and that happens frequently), I am required to use the Introjucer to update my projects, right? And the Introjucer rewrites them from scratch, erasing my settings, right?

Not always essential. Remember that each module generally provides one header file and one cpp file that your project includes. Those will probably never change, even if the things that they include does change.

[TheVinn]

Another way to create a project with the proper settings is just to clone an existing project, remove the old sources, and add your new sources in.

A great example of a working project with lovingly-tuned settings (and shared configuration files) is DSP Filters in my signature. In XCode it builds correctly for all iOS and MacOSX targets, and has shared settings. Under both Visual Studio 2008 and 2010 it also builds for 32 bit or 64 bit. If you download the Android SDK, the same Visual Studio 2010 project will work (you just need to add a target).

The only thing missing is the X-Windows/GNU/Linux version, which is a very small percentage - but coming soon.

The build settings in DSP Filters using .xcconfig files in XCode and Property Sheets in Visual Studio (both 2008 and 2010). What this means is that you can have a SINGLE group of build settings applied across the board to multiple projects. The DSP Filters application is a perfect working example, it consists of three projects: the demo application, the DSP Filters static library, and the Juce amalgamated standard library. The same setup is used under both XCode and Visual Studio. All three projects have shared settings. Change a setting in the Property Sheet or XCode shared settings, and they are applied to everything.

Note that these shared properties are edited using the NATIVE IDE and not by modifying the files manually. In Visual Studio this is done with the Properties floating palette, and under XCode the configurations show up as additional columns in the graphical build settings.

So, an alternative to using IntroJucer is to just make a renamed copy of the appropriate DSP Filters projects, and drop your source files in there. I mean, is adding source files such a significant value-add that we need a separate application to do it? Me personally, I prefer the power of shared project settings and hand-tuning the project file taking full advantage of the features of each particular build environment instead of the lowest common denominator that Bruce pointed out.

But it should not be an either / or proposition - as long as IntroJucer is not REQUIRED to build the Juce library, and we do not go overboard obfuscating the Juce source tree with obscure macros and include schemes, we can accomodate both schemes; As well as any yet-to-be imagined schemes that some enterprising person might invent in the future.

[Bruce Wheaton]

A great example of a working project with lovingly-tuned settings (and shared configuration files) is DSP Filters in my signature. In XCode it builds correctly for all iOS and MacOSX targets, and has shared settings. Under both Visual Studio 2008 and 2010 it also builds for 32 bit or 64 bit. If you download the Android SDK, the same Visual Studio 2010 project will work (you just need to add a target).

If you work on Windows/Visual Studio and if you work in the way you work, and if you don't need Linux, and if nothing major changes in juce, and if you'd rather be reliant on you than the Juce community?

No thanks. Not that I'm disagreeing - it should be possible to work with juce without using any tools (although that already isn't the case with 90% of Linux or FOSS projects), but this is a far less palatable solution.

Bruce

[Magrathean]

Something I've been thinking about doing is to provide another mode for the introjucer, which will let it create a "module collection" (better name needed..) instead of a project. A module collection would basically be a folder containing a bunch of modules and a generated header file for them, containing whatever options are needed. This could then be used by multiple projects if they all need the same module setup. A module collection could even be done as a static library, so you could compile it once and link to it from multiple projects.

This sounds great (particularly "A module collection could even be done as a static library, so you could compile it once and link to it from multiple projects"), I'd like to add my vote to request this please!

I see the value of a tool like the IntroJucer, but I also understand why people may want to use a different tool for their own code (I personally prefer CMake for generating my project files). The solution that you've mentioned above sounds like a good "middle ground", because the Juce library continues using IntroJucer to manage its own project files (and static libs if needed), but people can continue to use their preferred methods to generate project files for their own code (e.g. by referencing a "module collection" from CMake or hand-generated project files, etc).

[Arno1230]

Hi,

I am new here, however we do use Juce for a commercial product. I did not get all details of the discussion, however I want to confirm the opinion of the first post.

When you use Juce in a production environment stability of the code base is more important than the absolute top notch software design. Especially if re-design breaks existing code this can become a show stopper if it happens on a too large scale. We do have already trouble in upgrading to 1.53 because of the String redesign witch breaks all existing code that use toCString. Of course you can change everything but this means also that you have a re-test of the entire application to make sure you did not break anything. This can be a major effort for larger or more complex systems.
Or you can say you should not use toCString anyway, however this can only be true if the only lib you are using is Juce. This will not be true for most production projects.

I just fear now with another design upgrade we loose the support for bugfixes even more, since it seems to make upgrading even more dangerous.

You cannot force people to use the Jucer as project configuration management tool since it only covers Juce and a most projects consists of much more components that need to be build, often with various tools. And normally each company has a standard way how to build and configure software that you cannot just change on the fly. For e.g. e use MS Studio to manage solution and project files and have scripts to automatically generate make files for linux builds based on the MS files. You can like this or not, however, you cannot easily change this.

I just would kindly ask to be a little bit more careful with fundamental redesigns of the system. If this continuous I might get a hard time in justifying the use of Juce in our products.

Best

[jules]

Thanks, it can often be tricky to make these kinds of decisions, where redesigning something might break some existing code, but may also be essential for some kind of new feature..

The module stuff really shouldn't be too much of a big deal though, since really it's not much different to the way the amalgamated files worked, but done on a per-module basis. (And in fact, the old amalgamated files still work, by just including all the modules).