Yes, actually those are both good points - thanks!
Resuming this old topic because of some considerations: when JUCE is compiled as a library, some of the files dealing with graphics stuff (juce_Image.cpp and juce_LowLevelGraphicsSoftwareRenderer.cpp) are compiled with optimizations even for the DEBUG target, in order to achieve acceptable performances even when debugging.
Now, with a single juce_amalgamated.cpp file, how can one achieve the same result?
My project features a quite crowded Viewport that gets repainted often when scrolling, thus the performances without any optimization on Image and LowLevelGraphicsSoftwareRenderer are quite poor.
On the other side, enabling optimizations for the whole juce_amalgamated.cpp file will make me unable to step into those classes and functions. Not that it’s something often needed :), but it would be nice not to loose that chance.
For Visual Studio, I’ve seen some #pragmas that can be used for enabling and then disabling optimizations within a single file (see: http://msdn.microsoft.com/en-us/library/chh3fb0k.aspx ) but it seems there is no easy way to accomplish the same on mac or linux because this kind of option will be available only when adopting GCC 4.4 (according to what’s written here: http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html#Function-Specific-Option-Pragmas ).
Does somebody know a way to obtain such “selective optimization” within the single juce_amalgamated.cpp file?
Any news about this optimization thing?
Recently, another user seem to have had to cope with this in the debug version, as he states that the release version works just fine:
http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=4068
Hello jucers,
I’m really having trouble getting off the ground: under MS VSE 08 I have built the main juce part, and the amalgamator, but trying to build the demo has been unsuccessful - I get
(as well as another 180 warnings!)
I tried referring the #include <curl/curlbuild.h> to the actual file, only to be greeted with a similar error, and I should probably address the main issue instead of kludging around it.
amalgamator.exe said I didn’t need to write a new file…
Confused. very confused. Any advice would be much appreciated!
(yes, I’m a noob…)
EDIT. I might as well just go back to compiling without the amalgamated file…
i assume you are using the JUCED amalgamated version… just grab the latest JUCED version in trunk, or switch to JUCE (cause the standard juce don’t have curl based networking classes) !
It’s like you can read my mind… wow… I thought that I had downloaded the juced trunk… I’ll keep at it!
ok, this was a neat idea, granted, and I’m sure very useful to some. But is there some way we can proxy the use of it via the config so we can turn it on and off on a global basis?
The thing is just unwieldy and doesn’t play nice at all with any of the tools I use… such as Visual Assist or Araxis Merge… I’d love to just set some define to turn it off and delete the thing from my machine for good. But many projects (VSTs, demos, etc.) depend on it…
Like most of you, I’m sure you have customized some of the JUCE code… still I compile it once a week tops… and it becomes drudgery to merge the trunk with this beast infecting various projects and headers. Put it in a build step / batch file where it belongs… not while I’m trying to work with the code base… pretty please? 
I don’t understand what you’re finding troublesome? In your own projects you can just ignore it and use the normal libs… Why would mean you have to do more merging?
well, here’s an example…
juce_VST_Wrapper.cpp->juce_PluginHeaders.h->amalgamated.h
there’s really no reason for me to touch or customize juce_VST_Wrapper.cpp… I trust any changes are made due to bugs found, improvements, etc.
So this file is not really project specific, but when included directly, causes any “intellisense” type tools like VA to parse the whole thing, and things like “jump to definition” shortcuts can drop me right in the middle of a 55,000 line file. :shock: not particularly scroll friendly… 
The same is true for any project which contains source that directly includes amalgamated.h… Even with something like the juce demo… which I often use to test changes I make to the JUCE code base… would be nice not to have to merge / modify these projects every time I sync, or run the amalgamator to generate the (merged) source.
What am I missing here?
On second thought I’ll just replace the contents of the amalgamated header with the actual includes… just seemed it might be more useful as a global “switch”.
Ok, I see why that could be a bit annoying, but you could always just replace the include statement itself with “juce.h”, which is a pretty small change. Can’t really think of a neat way of making that any more configurable…
I in my code use a specific header called include_juce.h which looks like that:
#include <juce.h>
// #include <juce_amalgamated.h>
and I do a
#include “include_juce.h”
every time I need to include the juce headers.
That way, just swtiching the commented lines, will make the trick.
Maybe some similar trick, with #ifdef directives, could be used in JUCE as well, delegating the actual inclusion of the juce headers to a file which decides whether to use the amalgamated version or the ordinary one.
Of course, the preprocessor switch used to make the change should be either defined in the compilation options or at some early stage, BEFORE such a “disambiguating” header file.
yeah, via some define would be preferable, but even just a single include the way you have it means a dozen or so less files I have to look at when merging the trunk
i usually keep a couple of files in every app i create:
StandardConfig.h
//#define JUCE_ONLY_BUILD_CORE_LIBRARY 1
//#define JUCE_FORCE_DEBUG 1
//#define JUCE_LOG_ASSERTIONS 1
//#define JUCE_CHECK_MEMORY_LEAKS 1
//#define JUCE_CATCH_UNHANDLED_EXCEPTIONS 1
#define JUCE_STRINGS_ARE_UNICODE 1
// ..and so onStandardHeader.h
#ifdef JUCETICE_USE_AMALGAMA
#include "StandardConfig.h"
#include "juce_amalgamated.h"
#else
#include "juce.h"
#endifStandardLibrary.cpp
#ifdef JUCETICE_USE_AMALGAMA
#include "StandardConfig.h"
#include "juce_amalgamated.cpp"
#endThis way i can define JUCETICE_USE_AMALGAMA globally and voilà…