Cleanups and Tweaks for CMAKE

[baconpaul]

We have basically moved to CMAKE and this issue is just my cleanup list.

Things I want to fix

• why don't i need the png or svg for windows in the makefile?
• Comment the CMakeLists.txt more and properly
• linux install steps to cmake like on mac; and strip back build-linux
• add a build-win.something which does the whatzit rather than my crapulent powershell script. Or maybe just hack my crapulent powershell script
• cleanup surge.exp and surge.def in home dir which isn't needed
• move the source and lib definitions to src/CMakeLists.txt and lib/CMakeLists.txt
• https://cmake.org/cmake/help/latest/command/configure_file.html lets me make a buildinfo.h which I can use all over the place
• Tell the KX team and stuff
• surgev3-dll vs Surge.vst3 on windows target
• products in build dir and cleanup installers
• build-linux should use cmake --build blah
• strip -s on linux and mac

---

We've discussed a move to CMAKE several times. Among them, #137, #720, #761, #1143 and somewhat infamously, #1200. I figured it was best to consolidate the desire to move to CMAKE into a single ticket.

Right now we use premake5 and a collection of OS dependent scripts except for the non-installed headless asset which was our first foray into CMAKE. The subordinate surge-rack and surge-fx projects use platform-appropriate local build assets (Makefile and jucer/makefile respectively).

A move to CMAKE that was successfully executed for core surge would

1. Build all flavors (VST2, 3, AU, LV2) on our 4 platforms (mac, win32, win64, linux) as appropriate (so no AU on win, right now LV2 is linux only (but that might change - see LV2 Build Windows and Mac #1207) etc)
2. Support the optional VST2 for licensees and default off
3. Support the behaviors of the build-linux and build-osx scripts such as
   1. install local or global, including assets
   2. run au validation on macOS
4. Continue to build the headless asset all 3 platforms
5. Generate the platform-specific files for visual studio and Xcode users
6. integrate in both the CI and Release azure pipelines appropriately and construct the release assets we do today
7. update the developer documentation
8. notify the appropriate communities who maintain distro which build based on premake (we know there is one in arch, think there might be one in falktx / kx land) probably through chatting with folks in the lad IRC

I think in CMAKE some of these are easy, and some are work, but I don't know! This is not currently on my radar, but I'm happy to work with a developer who wants to do this.

[dvzrv]

This would be very much appreciated, as premake 5 is an alpha release (they have been stuck in alpha since 2015) and alpha releases will not be added to Arch Linux' official repositories (which is why surge will also not be added).

In general it is of course much easier to deal with only one build system for this project :)

[baconpaul]

Yeah I think the world would be a better place if it happened indeed! It’s not anywhere near the top of my stack right now personally - there are things in the synth ui and dsp code which are priorities and I don’t really know cmake (just like I don’t really know premake that well). But I would be thrilled to work with a developer and cmake expert who wanted to take a swing at it which is why I tried to write up the complete spec above.

[dvzrv]

@baconpaul I think a great intermediate solution would be to provide the Makefile(s) created by premake 5 in the source tarballs.
This would allow distributions to build surge with less effort (otherwise every downstream will have to track this manually, which is a lot of effort).

[baconpaul]

oh that's a good idea.

[baconpaul]

Just note to self: To do this you want to specify the tarball VM in the release pipeline so as to pin an OS, grab the premise for that OS, and then run it for all 3 operating systems so all the assets are there.

[dvzrv]

Meanwhile I've also pinged premake to maybe cut a release soonish (premake/premake-core#1423).

[baconpaul]

Great thanks. I thumbs-upped it. And I agree that, obviously, that's the easiest solution!

[baconpaul]

After a bout of frustration with premake I started tackling this. I have the head of the code on mac building headless, vst3, and au with cmake. Will tackle the vst2 and then can turn off premake mac.

From there it is a hop skip and jump to linux

My current strategy is that I am keeping the ancillary script (build-osx) which does the install assets stuff for now, just because copying files in CMake vs a script seems roughly equivalent. So I'll move from a combination of script + premake + build to script + cmake + build

Any help you may be able to offer this week or next testing would be appreciated.

[baconpaul]

OK so have mac working. Need to fix the 10.12 thing but I will push to nightly for now.

[baconpaul]

OK I have a branch where I can build the linux vst2 and vst3 with CMake and 0 premake. Will get the LV2 this week and will also merge it.

The only trick is going to be whether to port this to a stable release or just wait for 1.7. Depending on whether this is useful to you we can definitely discuss that once I have it working all three os.

[baconpaul]

Alright just merged the linux changes so now linux no longer requires premake