Out of curiosity, why is JUCE not available as a standard library, or perhaps a set of libraries?
I can imagine something like libjucecore.so, libjucegui.so, libjuceaudio.so, etc?
Applications would then link against it the same way they normally link against any other normal library.
(I’m just starting out with JUCE, so still getting used to having some 3rd-party library want to “embed” itself into my projects.)
In the Windows world they call that “DLL hell”. Years ago when I first started the library, it was DLL-based, since that seems like the obvious way to do it, but over the years I’ve come to really dislike that approach.
Juce has a whole bunch of option flags you may want to tweak, so if you have several projects with different settings, each one would need its own separately compiled and managed set of DLLs, and that’d be a PITA to manage, especially if you’re building on multiple platforms in several different IDEs. And once I’d got the modules system working, so that compiling the entire juce codebase directly into your project only takes a few seconds, I just can’t see the point in doing it any other way now.
I think it’s a shame really.
All linux distributions have managed to have a lot of shared libraries, including big ones like Gtk2/3, Qt3/4/5, boost and others.
I think this is probably one of the biggest reasons why there are not much linux-focused applications out there made with juce.
But that’s life
Yeah, but that doesn’t mean it’s the easiest or best way to do it.
And boost doesn’t use shared libraries, it’s headers-only. I’d make juce into a headers-only library if I could, but the way it works now is the next best thing.
Seriously, what could be simpler or cleaner than simply adding a library’s headers and a few cpps to your project? Having struggled with various cross-platform libraries over the years, I wish everyone did it that way.
Yeah, but that doesn’t mean it’s the easiest or best way to do it.
And boost doesn’t use shared libraries, it’s headers-only. I’d make juce into a headers-only library if I could, but the way it works now is the next best thing.
[/quote]
Parts of boost is header only, but a large part of Boost requires linking in the Boost libraries.
But as I’ve learned after I wrote this original post, this only matters if JUCE addressed the licensing issue. I didn’t realize a few days ago when I started that JUCE is only GPL, not LGPL. A library that doesn’t use LGPL is only open to other projects that happen to be GPL. In my case, I would like to contribute a GUI to several non-GUI open source projects I like on SourceForge. But I’m not about to introduce the mess of multi-licensing to established open source projects just so I can write a GUI.
I understand you have your preferences for including code directly into projects, but for the rest of us who link to libraries or use non-GPL open-source projects, what are we to do?
I downloaded FLTK last night, and have written my first few windows with it. But it is nowhere near as nice (from an API point of view) as JUCE. I was a IBM OCL/IUICL C++ GUI programmer in the 1990s, and JUCE seems to be almost a drop-in replacement for OCL! It is a pleasure to use. I would rather use it, but the license issue prevents that.
I really don’t see a licensing issue… I use GPL because I need to do the commercial license stuff, but I don’t see why it would stop you mixing the code with more permissive licenses like LGPL, MIT, etc…? The GPL forces you to make all the code public, and if some of that code is other libraries which are already public, then where’s the problem? I’d openly encourage that!
The GPL is viral. You cannot use GPL code, or even link with GPL libraries in open source projects (or closed-source projects!) without making the destination project GPL as well…or unless the library has a clause to permit such a thing.
So as long as JUCE is only GPL, then it cannot be used in projects which uses other non-GPL open source licenses.
I understand you need the commercial license stuff, I’m guessing you make your living this way, and I admire you for that. I wish I could do the same! But as for existing open-source projects, none of them can use JUCE unless either those projects decide to convert to the GPL, or unless JUCE is multi-licensed in a way which allows it to be used.
IANAL, but my understanding is that the GPL is viral in insisting that anything it touches must be made public, but nobody in their right mind would expect you to avoid mixing it with software that has a more liberal license. If you weren’t allowed to mix GPL with public-domain code, then no linux apps would be able to use zlib or libpng, or libjpeg, etc etc etc.
I have a million other things I need to think about right now, so am not going to get drawn into any tedious licensing debates, but let me publicly and catagorically assure you that I will not sue anyone for releasing a JUCE app on the grounds that it contains more liberally-licensed code!
That is because all of those libraries use the LGPL. The “library GPL” or “lesser GPL” allows you to link against LGPL code. The GPL, however, does not allow that. Let me assure you, this is probably the #1 reason why JUCE isn’t more popular than it is today. If JUCE had a clause to allow other open-source software to link against it, a lot more open-source C++ project would be using it.
One can make static libraries for windows, so the “DLL hell” argument sounds quite pointless to me.
Actually, compiling the juce codebase takes a lot more that “a few seconds”, and these “more that a few seconds” are multiplied by the number of Juce projects that are maintained. I can assure you that I, with many developers I’m in contact with, find this overhead very heavy in the development process.
Moreover, maintaining juce in each of these projects is also an overhead; you will object that we should use the introjucer to regenerate the project each time, but the project’s config is more complex that what the introjucer can generate. You can’t assume the developers just need the introjucer.
Having juce beeing compiled as a static library in one place (plus headers) would help us much.
Anyway I thank you very much for you work and the continuous support you provide to your clients/community. All the best
Nonsense. I just timed a complete rebuild of the Introjucer on my laptop in Xcode, and it took 7 seconds to build all the app’s cpp files (not just the modules!), plus another 5 seconds to link the whole project! And obviously the juce files don’t change, so will only need recompiling when you do a clean rebuild.
Seriously, if you’re worried about build times, invest in some extra memory and an SSD. As a developer it’s a false economy to waste your time waiting for a crappy machine to run.
Nonsense. I just timed a complete rebuild of the Introjucer on my laptop in Xcode, and it took 7 seconds to build all the app’s cpp files (not just the modules!), plus another 5 seconds to link the whole project! And obviously the juce files don’t change, so will only need recompiling when you do a clean rebuild.
Seriously, if you’re worried about build times, invest in some extra memory and an SSD. As a developer it’s a false economy to waste your time waiting for a crappy machine to run.[/quote]
Seriously, I have no room for improvement according to your suggestions: I already have an SSD, 4GB DDR3, I am forced by 3rd party libs to use llvm-gcc instead of llvm, which is generally 2+ times longer, and I continuously switch branch-to-branch so AppConfig.h (etc.) changes everytime; windows builds are no faster. It’s a matter of complexity, when having a multiplicative factor for build times, not just “optimizing your hardware” or “choosing the right software/config”.
Oh, and well, I just benched the juce_XXX.mm compile time alone: 1min 50s. Times the number of targets.
Ouch! Your machine is probably thrashing itself to death! You really can’t build properly without at least 8GB these days, and having just gone from 8GB to 16GB (with a similar CPU), my build times improved even more, so that’s now the minimum I’d recommend.
Ouch! Your machine is probably thrashing itself to death! You really can’t build properly without at least 8GB these days, and having just gone from 8GB to 16GB (with a similar CPU), my build times improved even more, so that’s now the minimum I’d recommend.[/quote]
I prefer not to take this the wrong way. So: no, I control the OS’s memory usage, it’s not thrashing at all. I would have admitted it on windows 32bit because it’s not able to use more that 2GB even if more memory is installed and pretends to use these 2GB+ available memory (you need windows 64bit for that), but not there. If we want to be sure about that, let’s ask other users to bench their compile time. Don’t take this badly neither, but your comment made me think of a former manager of mine who repeatedly proposed to solve complex issues by just buying a more powerful computer.
But once again, the issue really is the fact that the library has to be compiled with each target, not the compile time.
That’d be interesting. And maybe seeing the speed correlating with memory size would probably convince you that I’m right!
That’s not always a stupid decision. Given the choice:
a) Spend time and effort building and maintaining a more complicated build system, so you can run it on crappy equipment
b) Keep your build system really simple, and get decent equipment that can run it fast enough
I’d choose (b) every time.
I don’t doubt that it’s correlated. But maybe you will find that most of the Juce users don’t have such a great hardware config. Or maybe my project config is cluttered!
[quote=“jules”]a) Spend time and effort building and maintaining a more complicated build system, so you can run it on crappy equipment
b) Keep your build system really simple, and get decent equipment that can run it fast enough[/quote]
Having a separate target for a static library could make the build system really simple (build complexity of O(1) instead of O(n), n = project number, and removes multiple times duplicated juce configuration). Indeed, this needs time and effort.
Brother, I spent quite a bit of time in this thread explaining why this is a misconception. There is nothing stopping you from mixing JUCE with other projects which are permissively licensed. I provided a link which explains the nuances of mixing these types of projects together. You don’t need permission from anyone to do this, and no one else has to change their project licensing requirements.
Did you not understand?
Out of all the problems with JUCE, this is definitely not one of them. In fact, JUCE serves as the model of build performance which other libraries can only dream to achieve!
I agree that IntroJucer should not be required for practical development. But “maintaining JUCE” in your project is as easy as including the corresponding module .cpp files, of which there are at most 13 or 14 of? As long as Jules continues to provide the static library project you can browse, Find in Files in the JUCE sources, and set breakpoints easily without needing to use IntroJucer to produce your project file.
As I previously said (I’ll repeat myself, sorry): whatever the time taken to build Juce, it would be great to avoid compiling it along each of the multiple plug-ins/projects I’m working on, which depend on it.
I am asking this here after arriving here trying to improve compile times. My simple question is:
How can I use precompiled headers and juce. When I use them all of my files compile, but juce get tons of errors starting with:
etc…
I too, would like to use juce as a library. This would also eliminate the slow render times of juce in debugging.
On Windows 8 and VS 2010
Thanks
