With VST 3.6.10 SDK came a significant change. VST3 plugins on all platforms are now supposed to be distributed with a common bundle-like layout. The test hosts from the SDK expect this layout, so Linux testing #19 is aided by doing this. And while it seems bundling Surge is currently a bit hairy as it is, this layout is also supposed to make something like a universal bundle for VST3 possible.
I have done some work to set up this layout with premake, but it is currently incomplete, Linux-only, and feels pretty hackish.
whydoubt
All 33 comments
Take a look (in head) at scripts/macOS/package-vst3.sh perhaps? That creates a vst bundle from our .dylib which works in macOS vst hosts.
baconpaul
on 20 Dec 2018
I could prioritize cmake build over standalone work if you agree with the benefits it provides. I can do that fairly fast but does not make sense to do anything if premake5 if the way to go forward.
jarkk0sakkinen
on 21 Dec 2018
For packaging I would recommend to go with Flatpak and/or snap instead of any distribution packaging. They are very similar to what dmg provides.
jarkk0sakkinen
on 21 Dec 2018
I'm able to test cmake on Linux and macOS but need someone to test that it does not break Windows build.
jarkk0sakkinen
on 21 Dec 2018
Seems anyway kind of required groundwork even for standalone.
jarkk0sakkinen
on 21 Dec 2018
So for Mac we have the whole pipeline from source to a Mac pkg working using shell scripts. And @kzantow has windows packagers working on azure pipelines using a similar set of scripted activities
I don’t like premake very much from my one experience with it here but I wouldn’t replace it at this point. Rather I think we should figure out what’s the set of Linux packaging scripts which are appropriate. Like build -> packages vst -> rpm or whatever then put those scripts in scripts/linux and installer_linux from root
Other views welcome of course!
baconpaul
on 21 Dec 2018
Well, the dependency management is either broken or non-existent in premake5 depending on how view it and that is plain wrong. I can PoC CMake and you can decide then. The way I see it earlier the better because premake5.lua is only going to turn into a bigger mess .
jarkk0sakkinen
on 21 Dec 2018
@baconpaul @jsakkine are there other alternatives for project definition that can generate both Visual Studio and XCode projects?
kzantow
on 21 Dec 2018
Yes, CMake can do it and in fact VST3 SDK also uses CMake.
jarkk0sakkinen
on 21 Dec 2018
OK!
But I think this change is going to need to coordinate with a couple of moving parts. So let me tag a few folks
1: @kzantow is working on automating builds on azure using current script layout
2: @asimilon made the mac .pkg stuff work
3: I'm actively developing the C++ code on mac (but presumably that would be fairly transparent to your change) and need Xcode output for that
So we need to keep all three of those working if we are going to merge it right? Seems like quite a lot of work.
Please don't take this for me defending premake. Just pragmatism. Once we get linking everywhere I actually think the rate of change on the premake5.lua will drop and it will just sort of sit there...
baconpaul
on 21 Dec 2018
And also please don't take my comments for not being appreciative. Thanks for the work here and if we can pragmatically dump premake and have it all work, I'd be both happy and thankful!
baconpaul
on 21 Dec 2018
@baconpaul: I can PoC this with the current master and we can decide later how to integrate it. First just to see how well or not well it works. And I like argumenting :) I'm happy to rebase and fix conflicts in my CMake patch up until there is a good point in time to merge it. But first I just ignore that other work and create commits to my repository without doing a pull request at first.
jarkk0sakkinen
on 21 Dec 2018
@baconpaul @jsakkine last night I successfully built both Mac and Windows installers on Azure using the current toolset (I didn't test windows, of course). I don't mind changing it, but I am not a C++ dev by trade, so I'll be happy to have some help with the tooling. I've definitely used CMake with scripts/etc. others have put together, just never defined/modified them.
kzantow
on 21 Dec 2018
I do open source also professionally so for me rejecting patches is not really something that I take personally. Don't worry about that.
jarkk0sakkinen
on 21 Dec 2018
Sounds great. And yeah I've also done big open and open-like projects through my career so don't take it personally. But have learned that not everyone in the community does so try to be nice! Thanks for doing that also. Kinda of a cool little micro-community which has popped up here around surge.
baconpaul
on 21 Dec 2018
@kzantow: does it works for you if I initiate this work and you help me to finalize it. For example, I don't have Windows so if I make it work for Linux and macOS you could help with Windows once I have the foundations?
jarkk0sakkinen
on 21 Dec 2018
Or even better maybe I'll start with one platform and one plugin type and then ping you when I have commits to that? That way we can optimally distribute the work.
jarkk0sakkinen
on 21 Dec 2018
@jsakkine I also don't have windows ;) I can install a VM temporarily to figure it out, I'm sure. I just automated the current scripts in a Windows VM on Azure Pipelines.
kzantow
on 21 Dec 2018
I'll start with macOS AU target because that is easiest to get working and test. Once I have that done I'll ping you. After that we figure out the rest.
jarkk0sakkinen
on 21 Dec 2018
Sounds good.
I think if you can do mac AU and mac VST (they are very very similar) in one shot it will bang out a few extra bugs on the path. The approach in the current build scripts is really easy to follow as well I think (but I would say that, since I've been in them with @kzantow and @asimilon for the last week :) )
Good stuff.
baconpaul
on 21 Dec 2018
Awesome, then I'll just proceed with this :)
jarkk0sakkinen
on 21 Dec 2018
vst3sdk/doc/vstinterfaces/vst3loc.html has the pertinent info.
Nothing changed for macOS bundles, all the work is for Windows & Linux (assuming Linux was a single binary prior to VST3 SDK 3.6.10?)
Might it be a good idea to create a separate issue for CMake? Lots of discussion here about that, but the issue is actually about VST3 bundles.
I have to admit I'm really lost why it's come up, can someone explain the actual problem with premake5? (I'm hella tired, so that might be why it's a complete mystery to me!)
asimilon
on 21 Dec 2018
I don't think there's a problem, just investigating using other tools because people don't really like premake5?
Of course, maybe an even better solution would be Bazel :-D
kzantow
on 21 Dec 2018
@asimilon , @kzantow: hate would be the wrong word :) The only reason is the missing dependency handling e.g. no sane way to say
pkg_check_modules(GTK3 REQUIRED gtk+-3.0)
New and shiny is not something that adds value to this project, but mature well established features do help.
I'll stop here now, write the build recipe and create a pull request of which there is no rush pull. We can continue this discussion there.
jarkk0sakkinen
on 21 Dec 2018
There is now issue #137 and I'm already making progress making build files for CMake. Sorry for spamming this issue. More used to mailing lists where things kind of flourish more freely. Kind of forgot that this a ticket tracking system and not a mailing list...
jarkk0sakkinen
on 22 Dec 2018
OK, looking at my previous comments does not make that much sense where we are now. @whydoubt, where are going with this?
jarkk0sakkinen
on 10 Jan 2019
Is work proceeding with making Surge build with CMake? I had a ugly way to make premake do what I wanted, but was holding off on that to see what happened with CMake.
whydoubt
on 10 Jan 2019
@whydoubt looks like not much so any code you might have could be baked into a PR, right? and evaluated.. would be good.
p.s. would be lovely if you could join the slack at https://join.slack.com/t/surgesynth/shared_invite/enQtNTE4OTg0MTU2NDY5LTE4MmNjOTBhMjU5ZjEwNGU5MjExODNhZGM0YjQxM2JiYTI5NDE5NGZkZjYxZTkzODdiNTM0ODc1ZmNhYzQ3NTU
esaruoho
on 10 Jan 2019
@whydoubt, not at this point because the next release will be premake5. I've focused on other things for the moment.
jarkk0sakkinen
on 10 Jan 2019
query: what's happening with this one?
esaruoho
on 6 Feb 2019
I think it relates to #514 also...
baconpaul
on 6 Feb 2019
I guess we could close this one in any case.
jarkk0sakkinen
on 8 Feb 2019
The good info from whydoubt and zsimilon documenting whydoubt layout stuff is over in 514 so yeah I'll close this for now and leave it linked to that one
baconpaul
on 8 Feb 2019
Related issues
esaruoho
·
10Comments
VincyZed
·
5Comments
tank-trax
·
9Comments
baconpaul
·
5Comments
sense-amr
·
4Comments