Share Your Best Practices for Compiling for Compiling for Commercial Distribution!
-
Folks who do this commercially - what are your best practices for compiling? I'm writing the next chapter in my "Building Your Installer" tutorial, and I'm not an expert here. (Thank you to @d-healey and @Lindon for what I do know.) This is obviously macOS-focused. (I'd be happy to write a Windows one, but don't have Windows machine.)
How do you go about getting the fastest, most reliable code?
A few sample questions…ha -
-
Do you have two versions of HISE - one for development, and one for building releases?
-
Do you use the "CI" or "Release" schemes?
-
Are the any definitions/preprocessor-directives you use?
-
What Settings do you use in HISE (for building your plugin)?
-
What Settings do you use to build HISE, itself, for the version that will compile for your final plugin?
-
What are the safe optimisations?
-
What should ABSOLUTELY not do, but most people might miss?
OK, that's a lot, but I think we can all agree it would be helpful to have all this in one place.
On my end, I'll keep it all updated, and you can see the tutorial I've written so far.
Cheers.
-
-
@clevername27 said in Share Your Best Practices for Compiling for Compiling for Commercial Distribution:
Folks who do this commercially - what are your best practices for compiling
For my final builds for release I have a separate computer running proxmox and virtual machines for Windows, MacOS, and Linux - I also use this for testing as I can setup systems differently for debugging particular issues, for example if a user reports an issue on Mojave I can spin up a Mojave system and try and match their setup as closely as possible.
On each system I have a build script that downloads the latest version of HISE from github, builds HISE, downloads my project from github, builds that, codesigns it, packages it into an installer, codesigns and notarizes that. It's basically a 1 click operation, I just run the script and come back an hour later and the installer is there, ready to be sent to users.
-
git makes this unnecessary. On the few occasions I've had to go back to an old version due to a regression I just use
git checkout -
As a lone developer I haven't found any need for CI. If I was collaborating with multiple developers then it might be useful.
-
It varies for each project and OS. Here you can see what I'm using for Rhapsody.
-
Again it varies between projects a little but most of the settings (beyond company and plugin details) are the pre-processor definitions.
-
I add these definitions
USE_IPP=0 HISE_USE_EXTENDED_TEMPO_VALUES=1 HI_ENABLE_EXPANSION_EDITING=1 HISE_ENABLE_EXPANSIONS=1 AUDIOFFT_FFTW3=1 HISE_ENABLE_FULL_CONTROL_RATE_PITCH_MOD=1 HISE_USE_OPENGL_FOR_PLUGIN=1 HISE_DEACTIVATE_OVERLAY=1 NUM_HARDCODED_FX_MODS=6 USE_LATO_AS_DEFAULT=0 HISE_USE_MOUSE_WHEEL_FOR_TABLE_CURVE=1-
I think it's the most amount of optimization that is known to not cause issues.
-
Have more than one copy of the HISE source code on your system.
-
-
@clevername27 said in Share Your Best Practices for Compiling for Compiling for Commercial Distribution!:
So some explanation first:
I think Im in a slightly different place to Dave, he does consulting but I think most of his build work is for in house products, where as Im nearly 180-degrees opposite to this. I build a LOT of stuff for my client base, and only occasional stuff for my own product set, so I'm often very driven by deadlines - and very often limited in which version I use of HISE - it MUST MUST MUST include a reliable repeatable set of functions, so for example I haven't been able to run anything new since the Filter display bug (which doesnt seem to be fixed by the way) came up several months ago...
How do you go about getting the fastest, most reliable code?
A few sample questions…ha -
- Do you have two versions of HISE - one for development, and one for building releases?
Nope, see item 7. One only is all thats allowed
- Do you use the "CI" or "Release" schemes?
I just (mostly) use the native in-HISE menu option of compiling the product, if for some reason this is failing then I'm not keen on off-product work arounds and I try and get my product into a position where I just press EXPORT>target plugin...
- Are the any definitions/preprocessor-directives you use?
Well as a base place to start I go with;
HISE_SAMPLE_DIALOG_SHOW_INSTALL_BUTTON=1
HISE_SAMPLE_DIALOG_SHOW_LOCATE_BUTTON=0
HISE_DEACTIVATE_OVERLAY=1
ENABLE_ALL_PEAK_METERS=1I'm pretty sure the first two are no longer needed as they are replaced by the Deactivate overlay - and a note on this - I use my own in house installer for all assets(samples, images, wav files, met data etc.) so I don't want the plugin loading and trying to do installs, so really if you are wanting the plugin to load and save your Sample spot then the Overlay isn't any use to you.
- What Settings do you use in HISE (for building your plugin)?
Pretty standard out of the box - Im again not keen on introducing specific dependencies for products - I want to build them as efficiently as possible so that means as little fiddling about as possible.
- What Settings do you use to build HISE, itself, for the version that will compile for your final plugin?
Its a std build - and as I say only one build on the machine at any one time.
- What are the safe optimisations?
Nearly all the best optimisation are going to be in your instrument design, layout and HISE Script not in complier flags.
- What should ABSOLUTELY not do, but most people might miss?
- One version of HISE on the machine at any given time
- fail to use git -this is a double negative so let me say it clearer - GET. GIT. NOW! and then get a GitHub account and use this to backup (and occasionally restore) each project.
OK, that's a lot, but I think we can all agree it would be helpful to have all this in one place.
On my end, I'll keep it all updated, and you can see the tutorial I've written so far.
Cheers.
