Amalgamated debug


I have seen earlier reports that VC6 complains about the BIG amalgamated source file and stops emitting line-numbers after line 65537.

It seems that both VC8 and VC9 should have complained too, but do not. Line-numbers in the debug info or somewhere in the debugger seem to be masked to 16 bits.

Today, I was playing around with the jucedemo to see if the QTAudioReader would deal gracefully with protected AAC files (m4p) - which it does not. The jucedemo simply quits - no exception or anything … weird.

Anyway I tried setting a breakpoint in the QTAudioReader constructor on the call to juce_OpenQuickTimeMovieFromStream which is on line 18262 in my copy of the amalgamated source.
I then started the debugger.
During program initialization I got breakpoint hits in "PathFlatteningIterator::next() Line 18262"
but this function actually occupies lines 83632 thru 83854 in the file.

So it seems that the debugger cannot properly handle breakpoints in files
with more than 2^16 lines.

Obviously it is possible to do the debugging in the library version, but it is rather inconvenient to have to switch the config for this.

MAYBE a possible workaround would be to have the Amalgamator split the large file into files of 65500 lines and chain the files using include directives.


Yeah, it’s surprising that the compilers don’t just use an int for the line numbers, because although having 250000 lines is quite unusual, I bet there are plenty of people using over 65535.

I’m mostly using the non-amalgamated library for debugging, but it was an interesting experiment. Something you could try is building with juce_amalgamated_template.cpp instead of juce_amalgamated.cpp


Hi Jules,

I tried your suggestion about using the juce_amalgamated_template (both .h and .cpp) for debug and it works very nicely under VC8 & VC9.

The next thing I stumbled on was the plugin framework, more specifically the wrappers. First, thing the ‘demo’ project seemed to be broken - includes.h was missing.

Anyway, this was rather easy to fix, but out of the fixing process came a request for a tweak to the plugin wrapper code.

Would it be OK for you to use an include redirection for juce.h in the plugin wrappers ?

I don’t know if the following is readable at all, but I hope that you will consider dealing with the issues of moving code around without having to tweak the project or the environment too much. Its so much easier to copy an app and start tweaking away if you dont have to deal with include paths and stuff too much.

Below is my reasoning in the form of a short overview of how I set up my plugin projects.
I see three reasons for having the amalgamated concept:

  1. Control options from within the project instead of having multiple versions of the Juce lib.
  2. Ability to wrap up a project easily with a specific version of Juce
  3. Build speed (in some environments, I guess)

1 and 3 are easily achieved by including the source through the juce_amalgamated_template files.

2 requires that the source files do not reference other files from the juce source tree. This is however the case for the plugin wrappers

I like to keep my projects out of the Juce source tree. In fact I like to be able to move them to different drives and folders without changes to project files or build environment settings.

In my build-environment, I use a single standard include path for all my libs including Juce, so that Juce sits in a subfolder to this.

In order to be able to control whether the amalgamated or the library method of including the framework is used, I have done the following:

Local AppConfig. (without the comments) looks like this:

[code]// Compile in a project-local amalgamated copy of the Juce library

// Compile in sources instead of linking. No effect if JUCE_USE_LOCAL_AMALGAMATED is non-zero
#define JUCE_USE_AS_COMPILED_IN 1[/code]

I include the juce headers through a local juce_IncludHdr.h, which allows me to deal with the DONT_AUTOLINK_TO_JUCE_LIBRARY define.

Local juce_IncludeHdr.h:

[code]#ifndef JUCE_INCLUDEHDR_H

// Include projects local settings
#include “juce_AppConfig.h”

// Select header
#include “amalgamated/juce_amalgamated.h”
#include <JUCE/juce.h>
#include <JUCE/juce.h>

#endif // JUCE_INCLUDEHDR_H[/code]

I have .cpp files that deal with conditionally compiling in Juce and Wrapper code:


#include "juce_AppConfig.h" #if JUCE_USE_LOCAL_AMALGAMATED #include "amalgamated/juce_amalgamated.cpp" #elif JUCE_USE_AS_COMPILED_IN #include <JUCE/src/juce_amalgamated_template.cpp> #endif


#include "juce_AppConfig.h" #include "JucePluginCharacteristics.h" #if JUCE_USE_LOCAL_AMALGAMATED #define DONT_AUTOLINK_TO_JUCE_LIBRARY 1 #include "amalgamated/vst/juce_VstWrapper.cpp" #elif JUCE_USE_AS_COMPILED_IN #define DONT_AUTOLINK_TO_JUCE_LIBRARY 1 #include <JUCE/extras/audio plugins/wrapper/formats/vst/juce_VstWrapper.cpp> #else #include <JUCE/extras/audio plugins/wrapper/formats/vst/juce_VstWrapper.cpp> #endif

In order to wrap this up into a standalone project (that is, without the need for the Juce source tree) I copied the amalgamated files to an ‘amalgamated’ subdir in my ‘src’ folder.

I then made the following tweaks to the juce wrapper:

Moved the file

  • JUCE/extras/audio plugins/wrapper/juce_IncludeCharacteristics.h
  • JUCE/extras/audio plugins/wrapper/formats/juce_IncludeCharacteristics.h

Added the file

  • JUCE/extras/audio plugins/wrapper/juce_IncludeHdr.h

c) Tweaked the plugin wrapper sources (such as juce_vstwrapper.cpp)
so as to include juce.h through the file described in b) and take the characterstics check header from its new location one level further down the tree. That is:

changes to


changes to

In this way I am now able to copy the juce_IncludeCharacteristics.h and
any wrapper-format folders I need (only tried with vst on windows) into my ‘amalgamated’ folder and compile them from there, since it will now use my local project version of juce_IncludeHdr.h.

And now I am able to control how to compile the project just by tweaking the defines in juce_AppConfig.h.

Timing wise: For the demo vst plugin on VC9, I got

Amalgamated : 18 seconds
Compile in…: 21 seconds
Linked…: 9 seconds

In case the above is a bit overwhelming, I have zipped a copy of the amalgamated plugin and posted it here:


BTW: It might be that compilers use a 32 bit int for a POSITION in a file.
16 bits for the line number and 16 bits for the position within a line.