Juceaide fails to build on Windows - plugin demo - master branch

CMake
1

I just cloned the master branch, copied the CMake AudioPlugin demo to a new folder. Added a JUCE subfolder, set add_subdirectory('JUCE') and ran cmake from a build dir. Fails at at building juceaide. I have VS 2019 installed, with the very latest Windows SDK. Output is below. And in case it’s useful, here is the CMake cache. CMakeCache.txt (14.4 KB)

The Projucer generated projects build without any issues.

PS C:\Users\rory\sourcecode\AudioPlugin\build> cmake -DCMAKE_BUILD_TYPE=Debug  -G"Visual Studio 16 2019" ..
-- Selecting Windows SDK version 10.0.20348.0 to target Windows 10.0.19043.
-- The C compiler identification is MSVC 19.28.29912.0
-- The CXX compiler identification is MSVC 19.28.29912.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/bin/Hostx64/x64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/bin/Hostx64/x64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/bin/Hostx64/x64/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/bin/Hostx64/x64/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring juceaide
-- Building juceaide
CMake Error at JUCE/extras/Build/juceaide/CMakeLists.txt:89 (message):
  Failed to build juceaide

  Microsoft (R) Build Engine version 16.9.0+57a23d249 for .NET Framework
  Copyright (C) Microsoft Corporation.  All rights reserved.

    Checking File Globs
    Checking Build System
    Building Custom Rule C:/Users/rory/sourcecode/AudioPlugin/JUCE/extras/Build/juceaide/CMakeLists.txt
    Main.cpp
    juce_build_tools.cpp
    juce_gui_basics.cpp
    juce_graphics.cpp
    juce_events.cpp
    juce_core.cpp
    juce_data_structures.cpp

  C:\Program Files (x86)\Windows
  Kits\10\Include\10.0.20348.0\um\mapi.h(250,15): error C2279: exception
  specification cannot appear in a typedef declaration (compiling source file
  C:\Users\rory\sourcecode\AudioPlugin\JUCE\modules\juce_graphics\juce_graphics.cpp)
  [C:\Users\rory\sourcecode\AudioPlugin\build\JUCE\tools\extras\Build\juceaide\juceaide.vcxproj]


  C:\Program Files (x86)\Windows
  Kits\10\Include\10.0.20348.0\um\mapi.h(252,35): error C2279: exception
  specification cannot appear in a typedef declaration (compiling source file
  C:\Users\rory\sourcecode\AudioPlugin\JUCE\modules\juce_graphics\juce_graphics.cpp)
  [C:\Users\rory\sourcecode\AudioPlugin\build\JUCE\tools\extras\Build\juceaide\juceaide.vcxproj]


  C:\Program Files (x86)\Windows
  Kits\10\Include\10.0.20348.0\um\mapi.h(259,15): error C2279: exception
  specification cannot appear in a typedef declaration (compiling source file
  C:\Users\rory\sourcecode\AudioPlugin\JUCE\modules\juce_graphics\juce_graphics.cpp)
  [C:\Users\rory\sourcecode\AudioPlugin\build\JUCE\tools\extras\Build\juceaide\juceaide.vcxproj]
2

EDIT: I was using SDK 10.0.18362 when I wrote the following:

It looks like maybe the inner juceaide build is selecting a different (broken?) set of toolchain/SDK components from the outer build.

Are you using the “Developer PowerShell for VS 2019”? If not, that’s worth trying.

Running the following in git bash works for me here:

# copy directory from existing copy of JUCE
cp -r juce-dev/examples/CMake/AudioPlugin/ .
cd AudioPlugin/

# add a copy of JUCE
git clone git@github.com:juce-framework/juce --depth=1

# uncomment "add_subdirectory(juce)"
vim CMakeLists.txt

# configure the build
cmake -B cmake-build-vs
3

Just tested that. I still get the same errors.

I get the same fail there.

That was indeed the problem. Adding target_compile_features(juceaide PRIVATE cxx_std_17)
to the juceaide CMakeLists.txt fixes the issue, but having to edit this file manually feels a little off. I’m not very experiencing with CMake, but is there a way to set this property from the top level CMake project?

4

I’m not sure why changing the language standard would fix things. Juceaide should build with C++14 without any problems. The failure is in a platform header, so maybe that header can’t build in C++14 mode. I think this would indicate a bug in the header, unless it’s being misused somehow.

When I google “exception specification cannot appear in a typedef declaration”, the first result I get is for a compiler bug in VS2015, so maybe there’s still some breakage in the toolchain itself. Your MSVC version is a bit out of date (looks like update 9, but 11 is the most recent) so it might be worth updating and checking whether that fixes the issue.

5

Thanks, I’ll upgrade and see if that fixes it. :+1:

6

So I’ve updated my Visual Studio 2019 to the very latest version, and I have latest Windows SDKs installed, but this still fails unless I change the C++ standard to c++17 :man_shrugging:

7

I just tried updating my windows SDK from 10.0.18362 to 10.0.20348 and now I’m seeing the same thing. Perhaps it’s an issue in the latest SDK…

8

That’s what it looks like. FWIW, I’m also seeing problems with my Azure CI builds, where there were no issues before. They have also updated their Windows images to use the latest SDKs.

9

Not sure what to suggest in this case. It is possible to set a language standard on multiple targets by adding -D CMAKE_CXX_STANDARD=17 to your configuration commandline. If this allows the build to work for you, then maybe this will be an acceptable solution until the issue with the SDK is resolved. However, in general I’d recommend against this approach - target_compile_features is normally the way to go.

10

I can’t seem to get this to work? cmake .. -DCMAKE_CXX_STANDARD=17 results in the same problems from before. It doesn’t look like it propagates to the juceaide build?

This is fine. I can easily patch the cmake file. However, is there a way to check the target SDK and then choose the language accordingly, all within CMake? You’re the expert :wink:

11

It actually is, and I am stuck with the same problem as rory. They (MS) destroyed the mapi.h header in the latest SDK. Sadly the workaround listed here couldn’t be applied by me successfully:

I’ll try the language level C++ 17, but as I am targeting also older OS I feel slightly uncomfortable and rather would like to use the #undef trick they mention in that thread, I just don’t know how to apply that to juceaide.

12

That does not seem to work for me.

The first output of my cmake run is this:

Selecting Windows SDK version 10.0.20348.0 to target Windows 10.0.19043

(comes with VS 2022 Community), so that is probably the culprit with the new SDK being broken for non C++17 compilers. I always found JUCE’s build process a bit funny and different from everybody else, I fear I never understood the juceaide either.

13

Sorry, I was too fast. So yes, this does work if you add it to the CMakeLists.txt of the juceaide folder itself, as you wrote. Hm, I do patch JUCE anyway after cloning the submodule for some ASIO fixes recommended here in the forum, so this would just be another one…

I feel the #pragma #undef thing would be less intrusive that upping the language to C++ 17, but couldn’t get it to work with the build process.

14

This issue should be fixed on the latest develop. Have you tried updating?

15

Thank’s you’re right, it is fixed in 6.1.6. I had upgraded to 6.1.6, but somebody in the project had merged-downgraded us to 6.1.2 without us noticing, so I wasn’t on the latest version even if I thought I was. We stay away from non-labeled develop however, not sure if that is good thing, just a habit.