# Interesting new idea: Canned juce **URL:** \ **Category:** General JUCE discussion\ **Created:** [May 19, 2008, 1:32pm UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849 "2008-05-19T13:32:51Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [May 19, 2008, 1:32pm UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/1 "2008-05-19T13:32:51Z")
Got an interesting little idea that I’ve been tinkering with, and wonder what you all think of it… By some cunning hackery, I’ve found a way to create two files - juce.h and juce.cpp, which contain the entire library. Yep, the whole thing - all the source, all the 3rd-party libs like zlib, flac, ogg, png, jpeg, etc. The only external files that either of these include are system headers. So this means that to compile a juce app, you just need to include juce.h and add juce.cpp to your project. No libs to include (well, apart from the necessary frameworks on the mac). No need to build juce itself, just compile your project. The files are about 2MB and 8MB, so they’re big, but not unmanageable. Advantages I can see are: - no need to ever build the juce libs - massively faster to compile - on my mac it took me about 5-10 mins to build juce, but to compile the juce\_inline.cpp file takes under 30 secs. On my PC it takes under 10 secs. - no need to set up any library paths in your project, so things like the juce demo/jucer could build and run on a clean PC without the user needing to manually set anything up. - no need to keep different libraries for different configurations. You might (like me) have 10 different juce apps, each needing a different setup of some juce\_Config.h flags, debug, release, OSX version, etc., and that meant doing 10 different builds of the juce library, and somehow keeping track of all the libs that were produced. If it’s just a .cpp file, then each project can just set the config flags it needs, and each build instantly gets its own tailored version. - better code generation because the compiler is effectively being tricked into doing whole-program optimisation on the juce classes - ability to easily lock your project to a specific version of juce - just make copies of the two files in your project, and archive them along with your own code Disadvantages - more laborious when you’re writing code in the library itself, (but that probably only applies only to me and a handful of other hackers). It’s actually not particularly hard, though - I’ve written a utility that generates the two mega-files, and it only takes a a few seconds to run. - slightly more confusing when you need to debug down into juce code (but all the source is still there, just in a big file) - will probably break some compilers. I hit a few “internal compiler errors” in XCode, but by random tweaking these were avoidable. So… am I mad? Is this a stupid way to do things? Or will all programming be done like this in the future? Answers and opinions please! ---
**Author:** ![kunitoki](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kunitoki/32/15_2.png) [@kunitoki](https://forum.juce.com/u/kunitoki)\ **Post date:** [May 19, 2008, 2:40pm UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/2 "2008-05-19T14:40:23Z")
interesting idea. would be cool if you provide a separate version of the library in the canned version, besides the normal one, as i’m one of those hackerish developers that likes to put his dirty hands inside the library 😃 ah, in doing the canned version why not disable by default every JUCE\_XXX defines, and one enables it in his project before including the big juce.h so one can choose which things to enable/disable without opening the big juce.h and browse thousands of lines searching for JUCE\_DEFINES ? 🙂 ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [May 19, 2008, 2:48pm UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/3 "2008-05-19T14:48:11Z")
Well I’d still have the library available in its current form - there’d just be a couple of extra files in there that would work on their own. Not sure I understand what you mean about the defines? What would you have to search for? ---
**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\ **Post date:** [May 19, 2008, 4:05pm UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/4 "2008-05-19T16:05:24Z")
I like the idea 😃 sqlite guys did the same and it was pretty cool. Funny thing is that it usually produce faster code. ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [May 19, 2008, 4:20pm UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/5 "2008-05-19T16:20:09Z")
smaller code too… ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [May 19, 2008, 5:02pm UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/6 "2008-05-19T17:02:58Z")
Any suggestions for names for this? juce\_bottled.cpp? juce\_in\_a\_bottle.cpp? BottleOfJuce.cpp? JuceBottler.exe for the util that builds the big files? ---
**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\ **Post date:** [May 19, 2008, 5:41pm UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/7 "2008-05-19T17:41:09Z")
amalgamation ? ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [May 19, 2008, 6:11pm UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/8 "2008-05-19T18:11:11Z")
more of a conglomeration? juce\_incorporated.cpp? ---
**Author:** ![robiwan](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/robiwan/32/2446_2.png) [@robiwan](https://forum.juce.com/u/robiwan)\ **Post date:** [May 19, 2008, 7:51pm UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/9 "2008-05-19T19:51:23Z")
> [@otristan](#): > > amalgamation ? Second that. That’s what SQLite using the same technique is called. ---
**Author:** ![Tortyfoo](https://avatars.discourse-cdn.com/v4/letter/t/5e9695/32.png) [@Tortyfoo](https://forum.juce.com/u/Tortyfoo)\ **Post date:** [May 20, 2008, 6:08am UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/10 "2008-05-20T06:08:08Z")
+1 for Amalgamation Really like this idea as it has worked very well for SQLite. In fact SQLite now recommends the amalgamation version to be preferred version and only fall back to other versions if you have a compelling reason. Has the single file been preprocessed? ---
**Author:** ![andreas](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@andreas](https://forum.juce.com/u/andreas)\ **Post date:** [May 20, 2008, 7:15am UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/11 "2008-05-20T07:15:28Z")
I prefer to have the Juce library in the current form especially for multiplatform debugging and changing/fixing things. Putting it all together in a single source files might be a good idea for some reasons, but only as alternative. Would this single source file be platform independent or would there be a version for each platform? The structure of the subversion repository remains as it is now, does it? Andreas ---
**Author:** ![rebbur](https://avatars.discourse-cdn.com/v4/letter/r/ecae2f/32.png) [@rebbur](https://forum.juce.com/u/rebbur)\ **Post date:** [May 20, 2008, 8:22am UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/12 "2008-05-20T08:22:59Z")
It’s sounds great, especially this. > [@](#): > > - ability to easily lock your project to a specific version of juce - just make copies of the two files in your project, and archive them along with your own code We do tinker around in the libray itself…so for us that would be the only downside. ---
**Author:** ![haydxn](https://avatars.discourse-cdn.com/v4/letter/h/5fc32e/32.png) [@haydxn](https://forum.juce.com/u/haydxn)\ **Post date:** [May 20, 2008, 8:32am UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/13 "2008-05-20T08:32:41Z")
I love the idea! If you’ve made a tool to knock it together for you already, then it would be silly to not see how this ‘new form’ goes with us users 🙂 As for names, I reckon there’s no reason not to go along with the juice [sic ;)] theme. JuceBox? JuceCarton? Dose? Shot? Smoothie? ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [May 20, 2008, 8:48am UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/14 "2008-05-20T08:48:04Z")
[quote=“andreas”]I prefer to have the Juce library in the current form especially for multiplatform debugging and changing/fixing things. Putting it all together in a single source files might be a good idea for some reasons, but only as alternative. Would this single source file be platform independent or would there be a version for each platform? The structure of the subversion repository remains as it is now, does it? Andreas[/quote] I don’t think it makes much difference to debugging, really. You can still debug things, the only difference is that when you want to change something, you need to do it in the original source file, then run the re-amalgamator instead of rebuilding the lib. In fact, this is often quicker than rebuilding libs, especially on the mac. And yes, there’s only one file, containing all the code for all the platforms. ---
**Author:** ![spiderman](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/spiderman/32/431_2.png) [@spiderman](https://forum.juce.com/u/spiderman)\ **Post date:** [May 20, 2008, 9:13am UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/15 "2008-05-20T09:13:59Z")
I, for one vote for keeping the current style. I can’t imagine a monolithic file being other than an intermediate tool. It goes against module / functional separation and I think it’s only good for single-developer projects (I know, you are a one-man show, Jules, but there are those teams with commercial license 🙂 ). But I’d certainly love to give it a try. I guess I could use this for freezing easily replacable snapshots of juce, like others have said. Question coming to mind: do you plan to version control these files? How would svn react to them checked in with each revision (perhaps a non-issue). ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [May 20, 2008, 11:11am UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/16 "2008-05-20T11:11:16Z")
I’m not going to get rid of anything, just add these extra files to the build. (And probably update all the example code to use them instead of the old linkage, because it makes all the setup easier). Don’t think there’d be any issue with source control, as long as it doesn’t mind big files like this. ---
**Author:** ![kunitoki](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kunitoki/32/15_2.png) [@kunitoki](https://forum.juce.com/u/kunitoki)\ **Post date:** [May 20, 2008, 12:35pm UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/17 "2008-05-20T12:35:34Z")
> [@jules](#): > > Not sure I understand what you mean about the defines? What would you have to search for? i mean… you will have the juce\_Config.h somewhere inside the big juce\_Canned.h no ? how can i disable JUCE\_OPENGL for example ? i still need to sed the juce\_Canned.h searching where “#define JUCE\_OPENGL” is and comment it ? or i can enable it by defining it on my outer project ? what about adding JuceBottler project inside extras so we can use it for packaging a whole application with it ? with juce, external libraries (provided you have complete code available) and the current application sources ? ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [May 20, 2008, 1:35pm UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/18 "2008-05-20T13:35:23Z")
> [@](#): > > i mean… you will have the juce\_Config.h somewhere inside the big juce\_Canned.h no ? how can i disable JUCE\_OPENGL for example ? i still need to sed the juce\_Canned.h searching where “#define JUCE\_OPENGL” is and comment it ? or i can enable it by defining it on my outer project ? you’d just “#define JUCE\_OPENGL 0” either in your project settings or a header that’s included in all your files. Yep, the bottler will be in extras. ---
**Author:** ![X-Ryl669](https://avatars.discourse-cdn.com/v4/letter/x/a5b964/32.png) [@X-Ryl669](https://forum.juce.com/u/X-Ryl669)\ **Post date:** [May 22, 2008, 3:35pm UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/19 "2008-05-22T15:35:07Z")
I prefer the library approach, as big files usually results in ICE which are a PITA to debug. Can’t you simply put the agglomerator2000 in the repository, so we can use it on our own ? ---
**Author:** ![Bruce\_Wheaton](https://avatars.discourse-cdn.com/v4/letter/b/71c47a/32.png) [@Bruce\_Wheaton](https://forum.juce.com/u/Bruce_Wheaton)\ **Post date:** [May 23, 2008, 11:47pm UTC](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849/20 "2008-05-23T23:47:33Z")
Well, I’d say that it should be Condensed Juce, and maybe there should be a global define for JUCE\_PULP or JUCE\_NOPULP. Don’t know what they’d do, but that would be cool. Maybe whether juce is the app or is just a helper library. Good to get in it there somewhere. Very important. But it does sounds good. Would the condensed version stay up to date with the SVN tip? And do you see us compiling all the code right in the app, or still making a static lib? Bruce [Next page](https://forum.juce.com/t/interesting-new-idea-canned-juce/2849.md?page=2)