Installers

[d.healey]

I'm hitting a couple of issues with building via the automated script (building via the export menu works just fine).

Cleaning Builds but keeping the source code...
Loading the preset...Invalid script: The script you are trying to load is not a valid HISE script file.
The callback function onControl( is not defined.

I get this invalid script error but I've checked all scripts and they have onControl, except for some that are includes.

Then I get this a little later

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Platforms\Win32\PlatformToolsets
\v141\ImportBefore\Intel.Libs.IPP.v141.targets(90,43): error MSB4086: A numeric comparison was attempted on "$(IPPMajor
Version)" that evaluates to "" instead of a number, in condition "'$(IPPSingleThreaded)'=='0' AND ('$(UseIntelIPP)' ==
'Sequential' OR '$(UseIntelIPP)' == 'Sequential_Dynamic' OR ('$(UseIntelIPP)' == 'true' AND '%(ClCompile.OpenMPSupport)
' != 'true')) AND $(IPPMajorVersion) > 7". [C:\Users\John\Downloads\michaelasHarp-master\Binaries\Builds\VisualStudio20
17\Michaelas Harp_App.vcxproj]

[Lindon]

@Christoph-Hart yeah, but I'm not really looking for build automation. Like many things in HISE this stuff is great, in that its powerful and useful, but its very very brittle, unless I'm set up EXACTLY like you then it breaks and doesnt work at all.

[Lindon]

@d-healey
"Oh yeah I forgot to mention that. It's included in the build.bat instructions though"

so in the thing I'm supposed to be running are instruction that need to execute BEFORE I run the thing....

[d.healey]

@Lindon Yup, that's why I always read through scripts to figure out what they do.

@Christoph-Hart Might be a good idea to include that in the help section :)

[d.healey]

It just occurred to me to run --help on the HISE CLI. Useful reference

export: builds the project using the default settings
export_ci: builds the project using customized behaviour for automated builds
 - always use VisualStudio 2017 on Windows
 - don't copy the plugins to the plugin folders
 - use a relative path for the project file
Arguments:
FILE      The path to the project file (either .xml or .hip you want to export).
          In CI mode, this will be the relative path from the current project folder
          In standard mode, it must be an absolute path
-h:{TEXT} sets the HISE path. Use this if you don't have compiler settings set.
-ipp      enables Intel Performance Primitives for fast convolution.
-t:{TEXT} sets the project type ('standalone' | 'instrument' | 'effect')
-p:{TEXT} sets the plugin type ('VST' | 'AU' | 'VST_AU' | 'AAX' | 'ALL')
          (Leave empty for standalone export)
-a:{TEXT} sets the architecture ('x86', 'x64', 'x86x64').
          (Leave empty on OSX for Universal binary.)
--test [PLUGIN_FILE]
Tests the given plugin

set_project_folder -p:PATH
Changes the current project folder.

set_hise_folder -p:PATH
Sets the location for the HISE source code folder.
get_project_folder
Returns the current project folder.

set_version -v:NEW_VERSION_STRING
Sets the project version number to the given string

clean [-p:PATH] [-all]
Cleans the Binaries folder of the given project.
-p:PATH - the path to the project folder.

create-win-installer
Creates a template install script for Inno Setup for the project

[Lindon]

Im sorry but can we please get the "build automation/CLI" stuff into another thread, I'd really really like to concentrate on getting a usable installer script here...

[d.healey]

@Lindon I've just compiled all versions and created the installer using the build script, so it does work with a bit of fiddling. If you want to create your installer independent of the build script then just edit the WinInstaller.iss file to your needs and run it through ISCC.exe via the command line.

[Lindon]

@d-healey except of course it doesnt work like that. If I copy the file to my project folder and open it in inno then this line errors...

; VST
Source: "build\VST\{#AppName} x86.dll";

..because, and I dont know about your projects, but my projects have never had this structure... the dll is in
\Binaries\Compiled\VST{#AppName} x86.dll";

..so it means hand-editing it (which I dont mind doing), but again more Brittle behaviors.

[Lindon]

@Lindon So I will attempt to build a .iss file that works "out of the box" with a "standard HISE project structure" and if/when I get it working I will share it here.

[d.healey]

The build\VST folder is created by the automated build script. I wonder why it doesn't just use the usual folder structure though...

[Christoph Hart]

i think it had something to do with the AAX plugins which needed special treatment.

[d.healey]

Uninstallers...

I'm not familiar enough with whitebox or inno setup. Is it possible to make the uninstallers remove the configuration files that HISE plugins add to appData and where ever they are put on a Mac?

[Christoph Hart]

Innosetup creates an uninstaller automatically but weirdly there is no concept of uninstallers on macOS.

[d.healey]

@Christoph-Hart The inno one doesn't remove the config files though :(

[Lindon]

@d-healey correct... everything that your HISE product "installs"(Writes) then the installer - who has long since finished and gone to the pub --- knows nothing about - so the native installer has no idea about all that stuff in /AppData/Roaming etc...

[d.healey]

@Lindon But we do :) hence my original question. Can we make the uninstaller remove those files? I can do this easy peasy on GNU with a bash uninstaller.

[Lindon]

@d-healey well we are already at the limits of my inno knowledge here....:-(

[Lindon]

but theres this:

Inno Setup Help

(www.jrsoftware.org)

[d.healey]

@Lindon Thanks, I'll read through that.

[Dan Korneff]

Does INNO have the ability to let end users select what they'd like to install? Like a check box for vst, vst3 or aax?

edit:
found this thread that may help

Just a moment...

(stackoverflow.com)