Pre-build shell script done for EACH target?


#1

Juce 4.2.x switched to multiple targets, each plug-in is a target.
Does the pre-build shell script should run by design for ALL targets instead of one time?

It’s kinda confusing because:

  • pre-build is add to all formats.
    but…
    it’s also add to Shared-Code?

Post-build script
#2

Yeah that seems like an oversight to run this for the shared code target. However, I do see use cases to run this for each target. Imagine you are just debugging the VST-3 target: you’d want the script to execute as well. I know that xcode passes a whole load of variables to the script so it’s definitely possible to figure out for which target the script is currently being executed.


#3

I would say it’s very important to have the script run for each target. Although I haven’t upgraded everything yet my thinking was to use the WRAPPER_EXTENSION flag to determine which format is being built, the value should be non-existent for the shared code, if there is anything you want to run that is ‘shared’ by all the formats do it at that point.


#4

Please leave the scripts in every target. This goes along with “don’t introduce arbitrary constraints or make assumptions about build processes…” If the script is run for every target, it is possible inside the script to take different actions (including none) depending on target. If the script is arbitrarily left out of certain targets by PJ, then it is no longer possible for someone to have it run if their use case calls for it even in the shared code target.

Please always leave the maximum amount of flexibility - just because one person can’t think of a use case doesn’t mean a very valid (even critical) one doesn’t exist for someone else.


#5

On our case, the script was used for generating some code prior to the build it self. so now for example unless I add some detection of current target to bash I’m running the code 6 times.

A check box for add script to all targets would be fine.

Still, running the pre-build script in BOTH shared code and for each target is ambiguous. @frankfilipanits what scenario do you have requiring the script to run for each target AND the shared code?


#6

Detecting that the shared code is what is being built means that I can assume this is the first thing being built (as everything else has a dependancy on this), and it’s surely the only sane way to guarantee that a step is done and only done once. I use generic scripts across multiple projects some of which build for different formats, so I can’t see how I can rely on anything else other than the shared code for steps that must always run in all circumstances for all formats - but only run once (other than maybe writing to a file that i read again later but that seems much worse to me). On the other hand there are things I will want to do in the script that are format specific, for example I may need to add some additional resources for an AAX plugin. At the moment to detect which format(s) are being built I have to use the AppConfig.h, however this will now be unreliable because whenever the script is run it will say all the formats regardless of what is actually being built.


#7

For those who’re looking to single shot, with current Projucer, best resolution I’ve found is adding condition to our scripts:

# Since JUCE 4.2 there are multiple targets being built.
# Each runs the pre-build script.
if [[ $TARGET_NAME == *"Shared Code"* ]]; then
    <your script here>
fi

This for example builds only for shared code but of course can be used for adding different scripting for each target…


#8

just run into the same issue, because it runs the script also parallel i got horrible “race conditions”, because it was never designed to handle multiple starts of the same script


#9

Also check out this post: