Linux build questions

[agraef]

As I started maintaining an Arch Linux package for ShowMIDI on the AUR, I have a few questions on the Linux build:

• I'm currently using JUCE_CPPFLAGS_VST="-DJucePlugin_Build_VST=0" in the make command to disable the VST2 for license reasons, is that the right way to do it? I couldn't find anything more specific in the Linux Makefile.

• Also, is there a way to enable the CLAP plugin with a make option on Linux? I don't think that there's anything in the Linux Makefile at present.

• I noticed that libcurl4-openssl-dev is listed as a dependency in the Linux build instructions, but I don't think that this is needed? Maybe the README could be updated accordingly?

[dromer]

Ideally the whole project properly moves to CMake instead of this combination of projucer generated Makefiles for the core and CMake just for CLAP.

I summon @kottv to help with all the JUCE build woes ;)

[gbevin]

I would really like to avoid moving the whole thing to CMake for JUCE, we've tried to do it several times for the Moog apps and there's always problems. Using the ProJucer and native build methods for each platform has been working the best. The only way why CLAP is using CMake here is that they're not integrated as a feature in JUCE directly, and they've set up their system with CMake.

[gbevin]

You're right about the libcurl4 being removed now, I made that change in the ProJucer settings after writing that section in the README, I'll update it, thanks!

[dromer]

The problem with projucer is that you have to do individual Makefile exports on every platform, that's really a huge PITA especially in opensource projects.

Just look at SurgeXT, Bespoke Synth, plugdata and many other foss JUCE projects in how they handle their cross-platform builds.

Vendoring the entire JUCE code-base into the project is also not a very clean way to use such upstream code. Would really be best to avoid it.

Of course it's your project and you can organize things as you see fit.

[gbevin]

I hear you and I'm not going to change this, sticking to ProJucer comes from many years of doing commercial JUCE development and failing to get reliable builds all the way through code signing and Apple entitlements/sandboxing when going through the cmake route. I've spent way too many hours debugging that with my team, I'm not trying that again for a long time.

[dromer]

I've also not been enable to get the CLAP builds working btw, getting this error:

CMake Error at libs/clap-juce-extensions/cmake/JucerClap.cmake:41 (add_subdirectory):
  add_subdirectory given source "clap_juce_juce" which is not an existing
  directory.
Call Stack (most recent call first):
  CMakeLists.txt:44 (create_jucer_clap_target)

@gbevin of course it's harder to ask the community for help when working on proprietary projects, but in this case there are a lot of knowledgeable people that could help to improve this.

[gbevin]

@dromer you need to update all the submodules: git submodule update --recursive --init

[gbevin]

@gbevin of course it's harder to ask the community for help when working on proprietary projects, but in this case there are a lot of knowledgeable people that could help to improve this.

It's not really, like I said I've spent way too many hours on this in the past, and I know the community pretty well personally, including all the people working on JUCE. I hear you, but at one point I gotta manage my own time investment and only pick what is worth continuing to spend time on.

[dromer]

@dromer you need to update all the submodules: git submodule update --recursive --init

That's the first thing I did when cloning the project.

[gbevin]

Were there any failures? During the submodules update?

[dromer]

No failures. All submodules have been retrieved accordingly.

[gbevin]

Ah, you need to set the PATH_TO_JUCE env variable, this is the script I used myself to build and package on Linux: https://github.com/gbevin/ShowMIDI/blob/main/Scripts/build-linux.sh

You likely only need to look at it until line 22

[dromer]

Ok this comes back to me saying JUCE should probably be a submodule. It cannot be expected that others have the exact same version of JUCE available on their system. (or even having to need many different versions of JUCE since a lot of projects use specific versions or their own forks).

It is a bit annoying since JUCE repo, with all its history, is incredibly big. However it would make it much easier to reproduce builds using the exact versions required.

[agraef]

@gbevin, thanks for pointing to the Linux build script, I should hopefully be able to add the CLAP build recipe to my PKGBUILD and we'll be set on Arch.

[agraef]

Ok, I guess I'll have to build directly from git source then, since the release tarball doesn't contain the requisite submodules, and hence cmake won't find libs/clap-juce-extensions/cmake/JucerClap.cmake. But that shouldn't be a big deal.

[gbevin]

Ok this comes back to me saying JUCE should probably be a submodule. It cannot be expected that others have the exact same version of JUCE available on their system. (or even having to need many different versions of JUCE since a lot of projects use specific versions or their own forks).

It is a bit annoying since JUCE repo, with all its history, is incredibly big. However it would make it much easier to reproduce builds using the exact versions required.

Good call, I made those changes, JUCE is now a submodule and the build scripts are using that instead.

[gbevin]

Ok, I guess I'll have to build directly from git source then, since the release tarball doesn't contain the requisite submodules, and hence cmake won't find libs/clap-juce-extensions/cmake/JucerClap.cmake. But that shouldn't be a big deal.

Yes, you definitely will need to pull the submodules

[agraef]

Ok, I have this working now (https://aur.archlinux.org/packages/showmidi-git), but this PKGBUILD only works with current HEAD, as the latest release (0.6.0) still lacks the JUCE submodule. I'll have to wait until you tag a new release before I can give the stable package a similar treatment.

[gbevin]

Awesome, I'll do a tag later today then, thanks!

[gbevin]

I tagged 0.6.1

[agraef]

Awesome, thanks! I've just updated to stable AUR package to 0.6.1.

[gbevin]

@agraef wonderful, thank you!