Enhancing Installation of Eurorack-blocks

[ohmtech-rdi]

Hi everyone,

Eurorack-blocks is great, but a lot of you are just staying at the door, because the installation is not as simple as it should be.

On Windows, we have this situation where everyone seems to come with their own installation, and try to install Eurorack-blocks on top. Some are lucky, some are not. This shouldn't rely on luck and we should have a robust way to install Eurorack-blocks.

On MacOS with M1 processors, some of you managed to install it, but even me (the maintainer) has problem to get the install proper, as dependencies like cairo or ezdxf fails to install.

So basically, a lot of people are going to get stuck at everything about dependencies.

In my daily work, I tend to be quite conservative about dependencies. Being mainly a C++ developer, the trust level has a very high threshold. For sure the standard C++ library is a given (it is not the case for every project), but after that, question arises. For some project, even the high quality boost dependency is a no-go.

With this open source project, and because of time constraints, I gave a try at big dependencies like cairo, but in the end it is quite a mess, when we are potentially using 5% of their framework.

Internally with some projects running node, we've given a try at dependencies, and they seem to be very fragile and suffer very quickly from software erosion, at a rate quicker than I expected.

As more people have a genuine interest in the project (and you are much more than I first expected!), we need to start this discussion and collect your own opinion on how to make it proper. With enough diversity of opinions we can find something that will fit many.

I'll start with my opinions, but they are quite extreme — IMHO we should get rid of all dependencies that are not "trustable", progressively:

• The gcc cross compiler for ARM is a bit of an issue, but there is no way to get rid of it. However, the default install from ARM website is actually proper. I've used it in projects by downloading it and making it an artifact of the build system. On macOS and Linux, let's download it already on the first time it is built. I don't remember if the Windows has already an install of it, but if not we make a repo out of it. In any case, the installation wouldn't depend on a package manager, the install would be local to ERB, and all the ERB build system would therefore reference it (no PATH change)
• Cairo is a pain. It really seems it was not really meant to work on Windows from the start. Cairo with Pango doesn't work for fonts, the kerning is completely screwed. People reported that, and Pango doesn't seem to care so much. Though the freetype backend, that is used as a "toy backend" (by their word), have proper kerning. We don't use Cairo so much, things could be ported. Freetype is a different matter, but at least on the C side, it's pretty solid. We have more use of Cairo though, as with our new manufacturer system and the manufacturer we contacted for automatic production, EPS is required in their workflow (but we could generate that too). This is probably the biggest dependency to port, but the one that gives the most trouble as well
• DXF generation was not so much a pain, but began to be a pain with the M1. We use it only for drills and milling, so that's not a big deal. We could remove this dependency
• Soundfile has been a pain as well. We only use it to read WAV, and the Python binding doesn't support all of libsoundfile, and we will need Cue/Splice support soon. We already made a robust WAV parser in C++, so since we could get rid of all other formats in libsoundfile, I think we should just port it to Python.

On a side note, libDaisy is doing more or less something in the line of that for the cross-compiler, they install every dependencies with a binary distribution, for every platform they support (which are the one we want to support). It seems to be another way to address this installation problem.

What do you think about this? How would you do this?