Hey,

here is a roadmap to add CMake support for HISE. I don't plan to change the user or developer workflow for others. All changes can exist parallel to the normal "Projucer" workflow. Main reason for the support is to run static analysis tools on the project. CMake can create compile_commands.json files which can be read by other tools.

I've already done most of the work. The two commits are listed below. See Roadmap. What do you guys think?

Why

Here is a short overview why CMake makes sense:

• Faster builds
  • Ninja (Sometime 2/3x, when compared to running MSVC or Xcode from the commandline)
  • ccache (Super fast rebuilds, if not many files changed)
  • ClangCL/clang on Windows
• IDE Support
  • VSCode
  • CLion
  • Visual Studio (Open Folder)
• Export compile-commands.json
  • Used with static analyzers (clang-tidy and friends)
• Multiple build configurations without changing a file
  • Coverage, Sanitizer, Benchmarks, ...
• Package managment (conan/vcpkg/find_package/add_subdirectory)
  • faust, kissfft, mir, rlottie, zstd, ...
  • This is not realistic anytime soon
• Build each hi_* JUCE module in isolation
  • This will help find/cleanup cycles within the modules

Roadmap

• 10c42ec Update JUCE CMake files, they are not on 6.1.3 currently.
  • cp JUCE-6.1.3/CMakeLists.txt HISE/JUCE
  • cp -r JUCE-6.1.3/extras/Build HISE/JUCE/extras/Build
• 0ffc6b8 / c58672a Add CMakeLists.txt that can build projects/standalone
  • Add empty AppConfig.h (not needed with CMake builds)
• That's it

Wishlist

Change include style for JUCE module includes. This change can already be done, without changing any Projucer build settings, because the parent directory of each JUCE modules is added to the compiler include paths. So the HISE/JUCE/modules directory in this case.

It would enable to switch the JUCE root directory, if for example one is working on upgrading JUCE, the two directories could co-exist. Not possible currently.

// Convert from
#include "../JUCE/modules/juce_core/juce_core.h"
// to
#include "juce_core/juce_core.h"

// Same here, from
#include "../hi_lac/hi_lac.h"
// to
#include "hi_lac/hi_lac.h"

clang-tidy

Sample output from a clang-tidy run with performance-for-range-copy check enabled. Found 40 issues.

• performance-for-range-copy (40)

/home/user/HISE/hi_backend/snex_workbench/WorkbenchProcessor.h:321:13: error: loop variable
is copied but only used as const reference; consider making it a const reference
[performance-for-range-copy,-warnings-as-errors]
                for (auto f : filesToTest)
                          ^
                     const  &

Try it

git clone -b basic-cmake-support https://github.com/tobiashienzsch/HISE.git HISE-CMake
cd HISE-CMake

# If you have ninja installed
cmake -S . -B build -G "Ninja Multi-Config"
cmake --build build --config Release

# If not, cmake will select VisualStudio/Xcode
cmake -S . -B build
cmake --build build --config Release

@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:

• Fix warnings from clang-16
• [hi_tools] Cleanup includes and add missing module dependencies

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.

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)

@ulrik Once enabled, you should have these 5 extra:

@tsempire You can try deepl.com for translations. It's a lot better then google. If it has your language

@ulrik The output from exportAsBase64

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

SNEX

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 \

@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 Yup, looks like 7.0.6 JUCE ChangeLog

I'm trying to compile a custom node via the "Create C++ third-party node template". The base template works as expected and is loadable. As soon as I add a member to the C++ class (unique_ptr in this case)
the dll fails to load. The error message is rather limited, it says the file is missing, but is definitively there. what debug methods should I use to tackle the problem? Could this be a Linux issue? I can switch to Windows, but that PC is a lot slower.

Empty template

With member