Im wondering if cmake presets would be useful in this project?

[7sharp9]

RE: https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html

Im wondering if using cmake presets would simplify anything? Im finding my root cmake files are getting a little wild. Just pondering how this could be tamed a bit...

[sudara]

My understanding is that most of the audio community has only a very superficial understanding of CMake, so I'm worried about adding more complexity or abstraction. But it could be a good call, if kept very very straightforward.

Where are you running into problems in your CMakeLists.txt? Is it significantly more complex than pamplejuce's, and if so what's the nature of the complexity?

[7sharp9]

Well, I'm building a product and the getting it building on Windows seems to be the difficult part. Absolutely everything has been pretty easy with Mac Intel/Silicon. I was just wondering if this might be of help to cut down the cmake files a bit.

The bit where this has been pretty awful is the target_compile_options between different dependencies interacting and causing issues. For instance Google Highway like a /Gv option to optimize vector calls but this beaks juce completely etc. I also had issues which when MSVC was set to true, prior to the project call its's always false and I had certain setting that were never applied.

Long story short, is this probably wont help as this is more to do with pulling together different libs and trying to get a set of compiler setting applied correctly to each. I'm not sure there's a simple answer to that though...?

[sudara]

Oooh, highway looks cool, haven't checked that out. Are you a fan of it? It has a CMakeLists.txt, does it not take care of setting the options it needs on the target it makes?

[7sharp9]

Highway is pretty good, I did program my filter with intrinsic but with highway I ended up with them running quite a bit faster. I rolled my own juce IIR filters and they were about 2.5x faster too.

The issue I was having was highway has a recommended compiler switch on windows of /Gv which breaks juce. There was also another conflict where there was a mismatch of the CMAKE_MSVC_RUNTIME_LIBRARY something was overriding it with MultiThreadedDLL which was giving me linker errors because of the two runtimes. Its been a bit of a journey to find the right order to apply settings.

I ended up with something like this:

target_compile_options(SharedCode INTERFACE  /EHs)


# Add Release mode compile options directly to the plugin
if(CMAKE_BUILD_TYPE STREQUAL "Release")
    if(MSVC)
        target_compile_options("${PROJECT_NAME}"
                PRIVATE
                /O2
                /DNDEBUG
                #/Gv
                -DHWY_WANT_SSE4=1)
    endif()
endif()

I couldn't figure out how to apply /Gv to everything except the juce graphics parts which blow up.

[7sharp9]

p.s highways overrides EHs to /EHs-c- to turn off exception, but juce needs them.

[sudara]

I think in your position I would consider making a JUCE module which contains your dsp and the highway dependency. Make sure the module header doesn’t list juce graphics as a dep.

Isolating them in their own compile unit and target would allow you set different compile options on it, and the main project just consumes it (via add_subdirectory). Also would improve compile time on the main project…

[7sharp9]

@sudara That's a really good idea, not sure why it didn't occur to me! The two filters I have with highway support will actually be re-used in the next project. I'm build the plugin with a base level of sse support back to the nehalem times which is SSE4.
Intel macs: -O3 -DNDEBUG -march=nehalem -maes -mpclmul
Intel win: /O2/DNDEBUG -DHWY_WANT_SSE4=1

And then the highway code supports adds dynamic dispatch to: arm neon, sse3, sse4, avx, avx2, avx512. Its quite tricky to write code for filters that's length invariant but even so even fixed length vector operation benefit from the different SSE optimization's that highways outputs