i see the introjucer as a tool to handle cross-plattform projects. And yes, it adds another level of complexity, but why not?
yes, this is stupid, but it has also positive effect, all your different project exports are synchronized.
What concrete is missing, why not add this to introjucer?
What concrete is missing, why not add this to introjucer?[/quote]
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
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?
[quote=“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?[/quote]
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.
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.
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
[quote=“jules”]
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.[/quote]
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).
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
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).
