Ardour needs to be updated as it is bit rotting and getting in
the way of porting efforts:
http://marc.info/?l=openbsd-ports-cvs&m=145847514711662&w=2
I've spent a couple of days trying to update ardour to the latest
version (4.7).
Ardour 4.7 installs a couple of shared libraries which it partly links
to and partly loads at run time with dlopen. Without those libraries
ardour isn't functional.
The build system has been switched from scons to waf.
Ardour is using an old version of waf (1.6) which doesn't handle shared
libraries on OpenBSD properly. Libraries are named libsomething.so.0.0.0,
and are symlinked to so.0 and .so. I've tried convincing the build system
to name the libraries .so.0.0, but that's impossible without patching waf.
This problem is apparently fixed in waf 1.7.
Waf is shipped as a python script which contains a self-extracing
waflib directory (among other things). So the code is compressed
and it's impossible to patch the script as it is shipped with ardour.
This is a very packager-unfriendly design decision made by waf developers.
We can't just patch the build system like we could patch Makefiles.
To make this worse, arouder actually ships a modified version of waf,
with additional tools (autowaf) included in the compressed part of its
waf script. So downloading a newer version of stock waf from waf.io
and running that doesn't work. We'll need a custom waf script that
provides what ardour requires.
There is an option to build ardour with static libraries only. But this
option is broken since it doesn't work for all libaries shipped in the
ardour tarball. At least 3 of them still produce .so.0.0.0 instead of .a
if this the static-only option is used. So this doesn't help us and I
see no way of patching around it easily.
I have now run out of patience with this and I'm going to stop working
on it. I see three possible ways forward:
1) Accept the so.0.0.0 files generated by ardour and hope that upstream
will update waf eventually. The current git master still uses waf 1.6.
I don't think this matches our port guidelines but perhaps we can make
an exception?
2) Remove the port. Perhaps re-add it later if this situation has been
resolved upstream.
3) Someone else picks up on this and tries to wrangle a working waf into
my work-in-progress port (drop me a mail if you want to do this).
If this post is met with silence, or with general approval of option 2,
I'm going to pursue option 2. It's sad, because ardour is a great example
of a complex open source tool which meets professional needs.
I like having it available in OpenBSD for this reason.
But I suppose not many people run their recording studios on OpenBSD anyway,
and there are many other projects worth spending my time on...
