Usually no problem with building previous versions but hitting a wall on 7.4. [I build a copy but also install the ready to run binary in case of stability issues.]
Running latest Debian stable, lv2-dev is installed and this file is found here [if needed]:
waf cannot build due to this line in Ardour-7.4.0/libs/ardour/ardour/uri_map.h: #include <lv2/lv2plug.in/ns/lv2core/lv2.h>
verbose output section =
In file included from ../libs/ardour/ardour/lv2_plugin.h:35,
from ../libs/ardour/session_state.cc:110:
../libs/ardour/ardour/uri_map.h:30:10: fatal error: lv2/lv2plug.in/ns/lv2core/lv2.h: No such file or directory
30 | #include <lv2/lv2plug.in/ns/lv2core/lv2.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
We believe this is an issue with lv2 breaking backwards compatibility.
It is really bad practice for a standard to do that, and even more so in a micro version update.
thank you for the tip and fast response Robin! I agree with that its bad practice to break backwards compatibility.
I also forgot to mention the usage of KXstudio repos which is likely the source of that; ‘downgraded’ to the standard Debian pkg and the build seems to be succeeding. [It added /usr/include/lv2.h]
Which version of LV2 breaks this? I have not seen a problem yet with the Ardour provided lv2 1.18.8.
I see the latest version from lv2plug.in is 1.18.10, does that imply that the problem occurred in the differences between 1.18.8 and 1.18.10?
Did anyone file an issue at Issues · lv2/lv2 · GitHub yet?
There are only 4 open issues, none of which seem to match this problem description. I checked the closed issues and nothing recent seems to match this description either.
Are you sure it’s lv2 1.18.6 and later that’s breaking compatibility, as Ardour commit bf4decbfe7f6 suggests, and not random distro packaging?
I have 1.18.2, 1.18.6, 1.18.10 and 1.16.0 installed (self compiled under openSuse from LV2 git repo) and they all have lv2.h in the lv2plug.in/ns/lv2core subdir
I see: the default option of using old_headers makes it work as before but distros disabling that default option will possibly run into problems.
I don’t see that as a big fault on the LV2 side. If distros want to disable default flags until the sub projects have heeded the README and migrated to the shorter style header locations they should be the ones taking the blame.
Sure, if “new_headers” suddenly became the default when going from 1.18.5 to .6 I’d understand your concern.
But it really didn’t, and still isn’t in the latest git version. grep old_headers meson_options.txt on the source from 6 days ago still gives option(‘old_headers’, type: ‘boolean’, value: true, yield: true
I do understand that it puts an extra burden on you and Paul, as consumers of the standard, when some distros suddenly decide to flip the default when they upgrade to a minor release but I don’t think much, if any, blame should fall on the benevolent dictator in this case.
I see it as him giving a heads up that things will change in the future, and an easy way for people to test and make sure their programs will still compile whenever that change takes place.