Allow building against system libraries

[rekado]

I'm trying to package Radium for GNU Guix and I find it rather hard as the custom build system is rather inflexible.

There is no configure script that would set variables for the location of dependent libraries and linking is done against the compiled objects (e.g. OBJ14; I wonder if I could replace this with linker flags instead).

It would be great if Radium could use a standard build system with a configure phase or provide simple variables to prefer system libraries over the bundled library sources.

[kmatheussen]

I don't want to spend time on this. Regarding the bundled library sources, they are there for various reasons. They should not be replaced by system libraries. Those that can are not included.

[rekado]

That's very sad because it makes packaging so much more difficult. Guidelines for most popular GNU/Linux distributions such as Debian, Fedora, and GuixSD do not permit bundling for various reasons, meaning that it is unlikely that Radium can ever be installed through the official package repositories.

Would you be willing to accept patches (if I ever get far enough to actually build Radium on my machine)?

[kmatheussen]

It's simple to package it though, just build it, and copy the bin directory into e.g. /opt/radium, and make a symbolic link from /usr/bin/radium into /opt/radum/radium

[kmatheussen]

do not permit bundling for various reasons, meaning that it is unlikely that Radium can ever be installed through the official package repositories.

But this is extremely common. lmms, for instance, have patched versions of a bunch of ladspa plugins bundled. Same here, modified versions of some packages.

[rekado]

It's simple to package it though, just build it, and copy the bin directory into e.g. /opt/radium, and make a symbolic link from /usr/bin/radium into /opt/radum/radium

GNU Guix is a functional package manager without binary maintainer uploads (all packages are built in isolation in a chroot where only declared inputs are available), so I need to trace the complete graph of dependencies.

But this is extremely common. lmms, for instance, have patched versions of a bunch of ladspa plugins bundled. Same here, modified versions of some packages.

It is also very common for packagers to untangle excessive bundling to enable sharing at runtime and on storage.

[kmatheussen]

It is also very common for packagers to untangle excessive bundling to enable sharing at runtime and on storage.

Sure, but there are a few of the dependencies for radium that are better not to use any system version of. Those are placed in bin/packages.

[rekado]

Is it possible to build a minimal variant of Radium? In my workflow I prefer to route everything through JACK, so I like to have fluidsynth and PD (and more) running as separate processes instead of having them embedded in one application. I'm mostly interested in Radium because of its tempo automation and support for arbitrary meter changes (which seems rare among MIDI sequencers / trackers).

[kmatheussen]

Yes, you can build without Pd easily. Removing fluidsynth probably won't make much difference to the size of the program. Instead I would spend time removing VST support, which uses the JUCE library. Unfortunately, there's no flag which makes it simple to remove VST, but I'm willing to accept patches.

Anyway, to remove pd, just delete -DWITH_PD and libpds.a from build_linux_common.sh.

[rekado]

Okay, I'll try to play a little more with this over the next weeks. I've already been trying to remove VST support and link with external libs (such as rtmidi) as far as possible.

I'll prepare patches once I actually got it to build.

[rekado]

Seeing that the massive Visualization Library has also been forked and that separating the changes cleanly from upstream is a lot of work that would likely break non-GNU systems in the process, I decided to fork Radium and strip it down for my purposes, targeted at GNU systems with JACK.

I appreciate your work and applaud you for releasing Radium as free software!

[falkTX]

@rekado forking radium to make it easily packageable would be awesome. I looked into your account and couldn't see it though.

[rekado]

@falkTX I don't use Github much and have most of my code on http://git.elephly.net. However, after working a lot on untangling the code from the bundled libraries, and after removing a lot of dead code, I ended up with something that could be built but that had virtually no features.

I eventually gave up after realising that it would probably be less frustrating to write the application from scratch, using the appropriate upstream libraries (e.g. libpd) and focussing on GNU/Linux only from the beginning.

[falkTX]

ah ok, thanks for the info.

[kmatheussen]

For the record. Radium doesn't use libpd, but libpds, which is forked from libpd, but is much bigger.