Introjucer - I don't think I can get there from here


#1

I haven’t been playing with the 2.00 code before now, so this may be an old issue for some folks. But it feels like a serious potential problem and I’d like to bring it up.

I’ve been building plugins using Pace iLok security with Juce 1.53. I can’t reveal much detail because I’m under NDA, but it boils down to the fact that I have to add a Pace-specific annotation to files that are part of the build. On top of that, there are a number of rules that must be added to the project files–additional tools and scripts to be run during various build-phases. There’s no possible way that Introjucer can be cognizant of that, and no reason it should. While there’s some value in running Introjucer at the creation of a project, it’s a one-shot deal. After security measures are added to the build (and this could apply to all sorts of other tools, too) a later run of Introjucer will blow all that away.

With Juce 1.53, it turned out not to be too hard to manage this. I made a simple little wrapper file that simply defined symbols I needed (like JUCE_USE_CDREADER) and then included juce_amalgamated.cpp. My necessary Pace annotation came just before the inclusion of juce_amalgamated.cpp. Because the amalgamated file was a single giant blob of code, the annotation was good for everything inside. I tried making a similar file for 2.0 which included the files like juce_audio_basics.mm and so on, with my annotation in front of each. Turns out that those new juce files don’t want to be included by a single file and will hit an error condition if you try. Looks like I’m going to have to write a couple of dozen special little amalgamators added individually to the build. Any future runs of the Introjucer will have to spit data out to a harmless area that I’ll have to copy out of.

I’m aware that there are likely only a handful of Juce users who use Pace. But I’m sure that quite a few do have special-purpose scripts and build phases in their projects and will find Introjucer of little value after using it that first time. That seems a shame since there’s much that’s attractive about the tool. It would be nice to have way way for it to meet you halfway, spitting out a set of little include files that could simply be dragged into an existing project.


#2

And this is exactly why we need to make sure that usage of IntroJucer is optional and not required to get functionality necessary for development.


#3

There’s a place in the AppConfig.h file which lets you add your own code there, and that file gets included before all other files in the project, so wouldn’t that do the job for you?


#4

Or you can just use the JUCE amalgamation that I made:

https://github.com/vinniefalco/JUCEAmalgam

If you want to create the amalgamation yourself, the templates are here:

If you want to produce an amalgamation of your own source code, here’s the amalgamate tool:

Also…its in my signature :slight_smile:


#5

Might be able to wangle it around to get there, but that still doesn’t address the issue of all the extra scripts and build phases we have to get into our builds for various reasons.


#6

[quote=“TheVinn”][quote=“Mikey”]Or you can just use the JUCE amalgamation that I made:
[/quote][/quote]
Thanks Vinnie, but I’ve got it going now. I wrote a few little wrappers which still allows me to have individual module inclusion. I think it will be satisfactory, even though I completely gutted the AppConfig.h file. That may be my one and only use of Introjucer.


#7

Unfortunately I have to +1 this.

CMake is essential to a number of 3rd party libraries that are in common use here. If I can’t use CMake to build projects, i can’t use JUCE.

I can probably mess around creating a project in the introjucer, then back-porting it into a CMake list, but if other people need to get into and compile my code, that’s far from ideal.