CMake Support (Developer Builds Only)

tobante

@tobante Yup, looks like 7.0.6 JUCE ChangeLog

Christoph Hart

@tobante Hi Tobias, thanks for your work here!

Adding CMake support to the official HISE repo would be nice to have and probably lead to other nice things like CLAP support etc (IIRC this was a weird requirement for the current CLAP support in JUCE).

Please forgive me if I'll let you dig through that in autopilot mode, but I'm currently busy with other stuff, but I'll try to look into it when I find some time.

tobante

@Christoph-Hart Hi Christoph,

no stress, as long as I know that the changes can be merged at some point, everything is fine :)

CLAP support I also thought about, should be super easy with CMake. There is also Projucer support for the CLAP extensions, but they are a bit weird. You still need CMake as a build tool. I have never used it.

I will keep you posted here in the thread about news. Next steps are more tests on Windows, and then I will enable some more clang-tidy checks.

I try to keep my commits as minimal as possible, so I don't hinder your workflow for now.

d.healey

@tobante said in CMake Support (Developer Builds Only):

CLAP support I also thought about

What about LV2? :)

tobante

@d-healey Support for LV2 came in JUCE 7.0.0, so not at the moment. Would need to upgrade JUCE, but thats a bigger beast.

tobante

Next update:

Windows

Commits:
- 8cfe7df (ASIO)
- f390d06 (Warning flags)
- 01651d7 (Warning flags)

MSVC

Compiles and runs with Visual Studio 17 2022
- Both plugin & standalone
- JUCE_ASIO is enabled and the include path points to tools/SDK/...
- Ninja as a generator works (Faster builds)

ClangCL

Does not have the same SSE level enabled by default, but when enabled it compiles, but does not link.

clang

Clang (GNU style) unfortunately does not work yet. Am a bit confused by the error message. The compiler warns that the AppConfig.h is found using the Microsoft include style. It finds the file in projects/standalone/JuceLibraryCode, although this folder is not in the include paths. Actually the empty dummy file should be found in projects/standalone/Source/Config. Maybe this has something to do with the incude style ../../module/module.h vs. module/module.h. I do not know yet.

Linux ARM64

Commits: None necessary

After some playing around I was also able to build all HISE executables (standalone, VST3 & CLAP) on Linux ARM64. I had to disable LTO for this because I didn't have enough RAM otherwise. After that everything worked without problems. I tested it with gcc 10.2 and clang-17 on a RaspberryPi 4 (4GB). I don't have a screen connected to the Pi at the moment, so the only test was to send the CLAP version through clap-info.

CLAP

Commit: 536a690

I've added the clap-juce-extensions via FetchContent in CMake. Works as expected. I don't have a CLAP ready DAW, so the only thing I could test was to run it through clap-info. I tested on the following systems:

macOS 13 (M2)
Fedora 38 (AMD Threadripper)
Raspberry OS / Debian 11 (ARM64)

tobante

@Christoph-Hart

I think soonish would be a good time to merge my changes. For all the next steps I have planned, individual feature/bug-fix branches make more sense, as they are not directly related to CMake support. The current state is sufficient as a base to compile and run HISE on all platforms. There are 12 small commits including CLAP support (via CMake only).

The only two commits that could affect the Projucer workflow are the following:

All others, only added new files, or updated JUCE CMake files, which where unused before. Nevertheless it would be nice if people who have experience with HISE compiles could checkout my branch and test the normal Projucer workflow. Just to make sure that nothing is broken.

# Clone or download from GitHub
git clone -b basic-cmake-support https://github.com/tobiashienzsch/HISE HISE-CMake

Small question:

We need a directory to store common CMake code (warning flags, ...). Usally projects have a top-level project/cmake directory. JUCE has it under JUCE/extras/Build/CMake. My suggestion: HISE/tools/cmake.

tobante

I've added some of the projects in HISE/tools to the CMake files. CTest is now also enabled, and runs the tests from HISEStandalone run_unit_tests and hlac_tool unit_test. I needed to disable some 64bit tests in the hlac test-suite, not sure what's going on, Maybe because I'm not using IPP. Code coverage also works.

Commits:

CTest

Workflow is the same on all platforms, coverage should work on Linux & macOS, if gcovr is installed.

# coverage flags are optional
cmake -S . -B build -G Ninja -D CMAKE_BUILD_TYPE=Debug -D CMAKE_CXX_FLAGS="--coverage"
# build everything
cmake --build build 
# or only the test targets
cmake --build build --target HISE_Standalone hlac_tool
# run tests
ctest --test-dir build -C Debug --output-on-failure -V -j 2

# html coverage report excluding JUCE code (gcovr may take ~1min)
mkdir build/html
gcovr --html-nested -e ".*juce_.*\..*" --exclude-unreachable-branches --exclude-throw-branches --merge-mode-functions separate -r . -s build -o build/html/index.html -j 8
firefox build/html/index.html

HISE:

hi_lac:

hi_snex:

tobante

I just noticed that not all snex tests where running, so:

Add HISE_SNEX_TEST_FILES environment variable

Now test coverage looks a lot better. I also exclude all external code from the report (mir, rlottie, ...)

Modules
Screenshot from 2023-11-03 09-35-27.png

SNEX
Screenshot from 2023-11-03 09-35-36.png

gcovr

gcovr \
    --html-nested \
    -e ".*juce_.*\..*"  \
    -e ".*$build_dir.*"  \
    -e ".*hi_dsp_library\/dywapitchtrack.*"  \
    -e ".*hi_dsp_library\/fft_convolver.*"  \
    -e ".*hi_rlottie\/include.*"  \
    -e ".*hi_rlottie\/src.*"  \
    -e ".*hi_snex\/src.*"  \
    -e ".*hi_streaming\/timestretch\/signalsmith_stretch.*"  \
    -e ".*hi_tools\/gin_images.*"  \
    -e ".*hi_zstd\/zstd.*"  \
    --exclude-unreachable-branches  \
    --exclude-throw-branches  \
    --merge-mode-functions merge-use-line-min  \
    -r . \
    -s $build_dir \
    -o $build_dir/html/index.html \

tobante

Another minor update:

This should cover all "active" tool projects. I'm not sure what the status is with tools/markdown_editor and tools/rLottie Demo. Both have last changed in 2021.