Some ideas about the build system

[SunderB]

Hi :)
The new cmake build system is pretty nice and is a very welcome addition :) While the build system is being overhauled, I'd thought it maybe a good time to talk about a few thoughts/ideas regarding the build system (that may or may not be good):

• The build process for the server and gui are currently very intertwined. This is needed to some extent due to the shared resources used by both, but for example src code of external dependencies for the server are located in app/gui/qt/external and are built using build scripts in there. Maybe these would possibly be better off being moved to something like app/server/external? Alos, the idea of flattening the source tree has been brought up in https://in-thread.sonic-pi.net/t/spring-clean-to-enable-contributions/1733/2

• The system should make packaging for different platforms easier. Some work for has been done regarding this for windows, (and maybe macos) but it would be nice for it to be easy on all platforms. (E.g. to make an .exe; .app package; or .deb and/or .rpm package etc - I'm not too sure how to do this.) Also, for linux, maybe the file paths could be altered to be configurable (e.g. maybe via variables that are configured at build time), to make it easier to support FHS if desired.

• To setup the cmake environment theres been quite a few system console scripts added for Windows, Linux and macOS. Would it be beneficial to use ruby rake files in place of these to organise tasks, so we can use a full cross-platform (although with different shell commands/default configs depending on os) language for build scripts? Or maybe would it just make it more complicated and bug prone, with running shell commands and coordinating different parts of the project etc? I've recently been working on making something to try this out in my spare time. This could also integrate erlang compilation and then eventually bundling gems for the server and could possibly handle installation and packaging. (Note: I'm not saying I'd be able to fully complete a full implementation of this as I'm doing this in my spare time as a hobby whilst being busy with other things, so therefore I cannot concretly commit time to anything)

If you have any other thoughts or ideas about the build system please put them below so we can all discuss them :)

[cmaughan]

Firstly, the work I did here to enable CMake was the minimum possible I could come up with to move over. A bigger rework of folder structure/etc. was not something I wanted to dive straight into.
That said, I think flattening the source tree is a good move. For my own projects I follow a more traditional source code layout with src/include folders at the root, etc. Every change like this brings churn though, and as well as not having all the systems to test moving things around like this, I don't have the time either ;)

As you said, the windows system pretty much packages up everything with a single batch file command now; though there are a couple erlang compiled files and some UGens that aren't there yet. The external bits that are built by the main build are generated as a result of doing 'prebuild'. The focus of these bits is to build all the complicated depenendcies for Aubio on windows (which enables the Onset feature). And build the easier osmid library. Part of the reason for this is to make the development of the UI easy; since rebuild times are very quick. But agreed that moving these build bits over to a server/external would make more sense. There is actually no reason why the external bits could not be built on Mac/Linux too; but for now we just use the installed package. Building them manually from the source in external would help to get a consistent result.

There are some parts of external that are used by the UI - though they become part of the UI build; the Scintilla editor and kiss_fft. I moved the editor here to make it easier to debug/tweak, since it is integral to how the UI works, and the kiss_fft is the fourier transform for the spectrum analyzer I added.

At this point, the windows build consists of:

win-prebuild
win-config
cd build
cmake --build . --config Release
(in root/install/windows) : install.bat - to get an msi.

In an ideal world, similar scripts for Linux and Mac would do the same thing; I think getting to that point first might be a good idea before rearranging things.

I tend to follow this folder structure for my own stuff, and it makes more sense to a developer:
https://cliutils.gitlab.io/modern-cmake/chapters/basics/structure.html