I think its a little bit early to move to the latest post-quake-juce for my main-projects now, would be nice to have a list which issues/bugs exist in the old “pre-quake” repository.
I see you updated the old repository here and there, I’m wondering if theese bugs also will be fixed in the pre-quake version.
Also i would like to see, if we could use the post-quake version also like the old juce, without using the introjucer (which may overrides MS VC, xCode Solution files) in the future…
The new system doesn’t force you to use the introjucer any more than the old one did. But it does provide more functionality than the old one, so there’s more reason to use it.
I wasn’t planning on retro-fitting any changes into the old branch, as maintaining two branches would be too much hassle in the long-term… But if you want to request a few simple one-liners, then I could probably add them.
No, you don’t have to use the Introjucer.
I just used it for one example project to see how things have to be setup for the new module style juce.
Then I converted my projects to the new structure without using the Introjucer. I just had to change some paths and include some juce files into the projects.
No problems so far.
If you are doing a lot of stuff using other libraries, like I do, I think it’s easier to setup the projects on your own instead of using the Intrujucer.
547 // copy back any temp channels that may have been used..
548 for (i = 0; i < numOut; ++i)
549 {
550 const float* const chan = tempChannels.getUnchecked(i);
551
552 if (chan != nullptr)
553 memcpy (outputs[i], chan, sizeof (float) * numSamples);
554 }
I’m afraid of this because I am completely reliant on CMake. Anything that doesn’t integrate easily into CMake is a showstopper for me. Right now, I tell CMake where to find the static lib. If the static lib goes away and I need to start managing CMake lists for each JUCE update, I’m going to be a) sad, and b) using Qt.
The new stuff can still be compiled as a static lib, but the situation I’d like to get to is one where the introjucer can replace things like CMake, so if there’s something that CMake does which I could also support, please let me know.
For me it’s not so much what CMake can do, although its support for managing complex static library dependencies is superb, rather it’s a case of what it supports.
We use a lot of iTK, vTK code in our lab. If you have any experience of those systems you will know that trying to sidestep CMake is not a good idea.
Similarly, I personally use DCMTK in everything I do, and while DCMTK is not (yet) a fully CMake driven package, CMake’s rule selectors make it easy for me to create lists that can be used by others when linking stuff against that library.
Whether I’d want to or not, eliminating CMake from my life simply isn’t an option. I’d imagine that would be true for anyone who links against other large libraries that aren’t boost.
I did consider that option, and I was wondering if I might just end up writing a script to extract and build the CMakeList myself.
For CMake users the ideal approach would typically be to have the introjucer produce a JUCE + configuration + modules CMakeList file, and for those that want it, a project CMakeList.
If the introjucer could do that, it’d probably work well for me. Is this something you’d want/need help with?
If the introjucer is tied to the philosophy that there needs to be a user project involved then it’d probably be acceptable to have the introjucer create a combined CMake, but a trick here is that the generated VS/XCode projects would need to know about the CMake rules. That’s why it’d be better to let the CMake tool create the project files. That way, the user would just tell CMake where to find the auto-generated JUCE CMakeList, and a miracle will occur.
A CMake target would probably be pretty simple to do, the architecture is all there to handle new types of targets. It’d probably be similar to the linux makefile generator class. Not something I’ll have time to look at in the near future, but I certainly want it to be possible to support that kind of thing.
Weird, it seems one of my posts in this forum is missing. Jules I only have two concerns about the restructure of Juce, and I would like you to address them directly:
IntroJucer not required to build
Still possible to produce a multi-file amalgamation using my shell script
For reference, please have a look at my Juce directory in dspfilterscpp SVN:
There you can find the shell script, the four file amalgamation, and the 8 files that get included in projects (4 .mm for mac, 4.cpp for everyone else). Will it be possible to continue this model?
[quote]Jules I only have two concerns about the restructure of Juce, and I would like you to address them directly:
IntroJucer not required to build
Still possible to produce a multi-file amalgamation using my shell script[/quote]
Not sure what I can say that I’ve not already explained… It’s possible of course to build without the introjucer if you have some kind of moral objection to it. These things are just a bunch cpp files after all. And since they’re just a bunch of cpp files, running the amalgamator on them is possible if you want to do that.
