Amalgamation Sensation sweeping the Nation!


#1

Jules:

Whatever you do, PLEASE make it available, or provide a tool, that will turn the entire juce source tree into an amalgamation of as few .h and .cpp files as possible that can be inserted into a project to quickly provide juce support. I plan on publishing a number of small open source apps and I really want their repositories to be self-contained. It’s easier that way and doesn’t require the user to go get juce separately.

Thanks!


#2

Won’t the module system allow you to do something similar (self-contained)?


#3

Yesterday’s check-in of the introjucer now supports the embedding of modules into your project!

In the list of modules, each one has an option box that you can tick if you want to keep it inside your source tree - if you do so, it’ll automatically copy the module into the JuceLibraryCode folder, and update everything to refer to it.


#4

I dont want to use introjucer and I dont want to embed modules. I just want a small handful of .cpp, .h, and unfortunately a couple .mm files for mac that I can just add to my project and get instant Juce gratification.

PLEASE!!!


#5

Well, you can amalgamate the modules yourself if you want to! The amalgamator’s open-source, you get it to do that… Can’t honestly see the point, though!


#6

It makes it easier to produce self-contained projects by using an amalgamation. This way, the person who downloads the open source project does not have to go and get Juce.

Imagine downloading an open source program that had boost, libcurl, etc… as dependencies, and required that you first download, build, and install those packages before you can compile the open source program. It sucks.

With an amalgamation (of several small files, because of the compiler limitations you pointed out), Juce can be simply included in the open source project, thus allowing for no external dependencies.

Trust me Jules! You want to keep providing an amalgamation of some sort…or give me a script that will produce it.


#7

But that’s exactly 100% the reason why I’m doing this module stuff! I also think self-contained projects are the best way to do it. I’ve just changed my mind about the idea of having one big .cpp file instead of a bunch of included cpp files. That’s all. I do still very much think they should live inside your project, and I’m building tools to make that easy…


#8

The amalgamation doesn’t have to be one big .cpp (although that would be the best way). I can settle for 4 or 5 .cpp files (because of the compiler issues you mentioned). If the amalgamation can be a single .h that would be perfect but if it also has to be broken up into 4 or 5 because of the compiler then I can live with that.

My ideals for the amalgamation are:

  • small number of big .cpp files
  • 1 or few large .h files
    . tiny .mm to simply include the .cpp
  • everything in one folder that I can put in my project as a sub-folder

#9

Well, I’m going to give you all those, except that instead of

  • small number of big .cpp files

you’ll get

  • small number of .cpp files (that probably include some other cpps)

#10

[quote=“jules”]
you’ll get

  • small number of .cpp files (that probably include some other cpps)[/quote]

Fine, so I can still run Amalgamator (once I figure out how to get it working) to produce the amalgamation satisfying my needs?