Switch swh to submodule

[tresf]

Moves the "swh" LADSPA plugins to pull from upstream swh/ladspa by building the source from a git submodule. This requires a few new build tools over what we use today, namely perl and perl-xml.

Before

plugins/LadspaEffect/swh/acconfig.h
plugins/LadspaEffect/swh/alias_1407.c
plugins/LadspaEffect/swh/allpass_1895.c
[... 109 total files ...]

After

plugins/LadspaEffect/swh/CMakeLists.txt
plugins/LadspaEffect/swh/ladspa@ 5edf95c -> Points to http://github.com/swh/ladspa
[...]

New Dependencies

perl libxml2-utils libxml-perl liblist-moreutils-perl

Once merged, the dependencies must be updated on the wiki. Supercedes #3489, related #296

[gi0e5b06]

swh-lv2
swh-plugins (ladspa)

SWH is a package on most GNU/Linux distros. No need to make it a submodule, no need to have it as part of LMMS.

[tresf]

SWH is a package on most GNU/Linux distros. No need to make it a submodule, no need to have it as part of LMMS.

Thanks. We know. But this is the exception and not the rule and the systems you mention have packagers that already take advantage of this.

So in summary, the statement is not true for any use-case we care about... OUR installers.

Our installers include: Windows, MacOS & Linux AppImages (our ONLY official distribution methods).

Bundled installers need this and we will continue to bundle in this fashion until a better solution is provided

[gi0e5b06]

Windows: https://www.fosshub.com/Audacity.html/LADSPA_plugins-win-0.4.15.exe
MacOS: https://www.fosshub.com/Audacity.html/swh-plugins-mac-0.4.15.zip
AppImage: no one is using that (and anyway there is the package)

It would be better to support DSSI, LV2, VST3 and Nyquist plugins instead.
And Audio Units on MacOS, and native VST on both MacOS and Linux.

[tresf]

It would be better to support DSSI, LV2, VST3 and Nyquist plugins instead.
And Audio Units on MacOS, and native VST on both MacOS and Linux.

You're going off topic.

MacOS: https://www.fosshub.com/Audacity.html/swh-plugins-mac-0.4.15.zip

I'm not sure the point. The fact that some unrelated 3rd party provides binaries doesn't negate the value this PR has. We may eventually decouple our packaging as well, but that's out of scope. This PR explains its purpose and it's something that's been discussed for several months. Perhaps you need to jump on Discord? https://lmms.io/chat

[tresf]

AppImage: no one is using that (and anyway there is the package)

Again, off-topic. If you have issues with AppImages or the popularity thereof, please place them in the appropriate channels (#devtalk on Discord or any of the AppImage issues on this tracker).

On a side note, you've been asked several times to improve the quality of your contributions on GitHub.
This is your first warning. After three, you will be removed from our tracker. Let's keep comments on-topic and progressive, please. If you have a problem with this, we can discuss privately or publicly on Discord.

[lukas-w]

This is your first warning.

I feel like this already is the third warning: (1) #3422 (comment) (2) #3876 (comment)

[tresf]

This is successfully compiling on all platforms. I'd like to point a few things out...

1. I put a submodule guard in here to avoid any strangeness with non-empty directories. We can likely standardize this into a macro (e.g. SUBMODULE_CHECK(swh/configure.ac)) and use it as a standard moving forward. It's a very basic check but it can help us move contributors away from confusing error messages. This will become more important as we add more submodules. So far, we have malloc, zynaddsubfx and swh . This list is going to grow.

2. This PR contains patches that don't belong in LMMS source code but are required for compilation. Upstream PRs have been opened and will supercede those patches. I'm going to give Steve Harris (swh) a few days to merge, which he's very good about. Then I'll bump the submodule to the HEAD of upstream.

3. If anyone has feedback on the "rube-goldberg" approach to building this project, speak now. I've considered asking upstream to switch to cmake, but the author no longer maintains this, so this would have to be done by a community member instead. The perl/xml template dependency makes this project a bad candidate for cmake I feel, but thoughts are welcome.

4. Speaking of ^rube goldberg, there's an inefficiency added to compilation where the .xml files are coerced into .c files every time cmake is run. These should be cached and only updated as the .xml files are changed, but I don't know the best way to do this. Advice is appreciated. If I can't figure it out, I'll leave the FIXME in there and attack it at a later time.

[lukas-w]

1. We can likely standardize this [submodule guard] into a macro (e.g. SUBMODULE_CHECK(swh/configure.ac)) and use it as a standard moving forward. It's a very basic check but it can help us move contributors away from confusing error messages.

Good idea 👍. We can even run git to fetch the submodule automatically if it's missing.

3. If anyone has feedback on the "rube-goldberg" approach to building this project, speak now.

I'm slightly worried about what this means for building on Windows, especially regarding the perl dependency. It may be more portable to generate the .c files once, upload them on e.g. Github Releases, and fetch them at build time using ExternalProject_Add. But then again, the .c files will likely need fixing for MSVC anyway.

4. […] there's an inefficiency added to compilation where the .xml files are coerced into .c files every time cmake is run. These should be cached and only updated as the .xml files are changed, but I don't know the best way to do this.

Use add_custom_target or add_custom_command instead of execute_process. They have a DEPENDS option where you can specify a list of files to watch for changes.

Something like this could work:

FOREACH(_item ${XML_SOURCES})
	SET(out_file "${_plugin}.c")
	GET_FILENAME_COMPONENT(_plugin "${_item}" NAME_WE)
	ADD_CUSTOM_COMMAND(
		OUTPUT ${out_file}
		COMMAND ./makestub.pl ${_item} > ${out_file}
		DEPENDS ${_item}
		WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/swh
		VERBATIM
	)
	LIST(APPEND PLUGIN_SOURCES ${out_file})
ENDFOREACH()

Then use the resulting PLUGIN_SOURCES list instead of globbing.

[tresf]

@lukas-w done via 38d0e37 (rebased, ea69da7) as well as some other cleanup and the first draft of the submodule/git script.

[lukas-w]

Great 👍 I'll have another look at the CMake scripts soon.

[lukas-w]

I think it's better to just use FIND_PACKAGE(Git) here instead. No need for an extra CMake module.

[tresf]

I'll switch to FIND_PACKAGE(Git) and use GIT_EXECUTABLE variable, thanks. This module was originally added to look for some of the automake/autoconf/autopoint tools that weren't trivial to locate, but I've since realized we don't need them if we build with cmake. Thanks. I'll retire the module for now.

[tresf]

The following upstream patches have been merged:

• Remove broken lookahead_limiter swh/ladspa#56 - Remove broken lookahead_limiter (So we can glob everything)
• Use List::MoreUtils instead of List::Util swh/ladspa#53 - Use List::MoreUtils instead of List::Util (Ubuntu 14.04 compat)
• Allow older versions of gettext swh/ladspa#51 - Allow older versions of gettext (Ubuntu 14.04 compat)

The following upstream patches are still open:

• Windows compat fixes swh/ladspa#52 - Windows compat fixes

.. once merged all patches and plugin blacklisting can safely be removed from this PR and we can simply fast-forward the submodule to be in sync with swh/ladspa upstream master.

[lukas-w]

Merge now or wait for swh/ladspa#52 to be accepted?

[tresf]

My instinct is to wait.

[tresf]

Upstream has been merged. Squashed to two separate commits. This PR should be "rebased and merged" once Travis is looking OK.

[tresf]

Dependencies for Ubuntu have been updated. Note, I have not updated Fedora, Debian or the others at this time. I also do not recommend updating Qt4 listing as we will drop Qt4 support with the master branch as soon as someone has the time to do so.

Another disclaimer for Windows coders... (e.g. @DomClark), this will also break master builds on Windows desktop with WANT_SWH enabled until we have the tools installed and documented properly. Our Windows build tutorial is grossly outdated since switching to Qt5, so this is a separate task and any help is appreciated.