[Bug]: JUCE build artifacts differ from CMake convention

[DaAwesomeP]

Detailed steps on how to reproduce the bug

Hello,

The JUCE CMake build framework solves a lot of problems and makes it very easy to quickly get started, but it does make it more difficult to package applications using CMake tooling. Here are a few of the issues I have run into:

• Always builds into non-configurable *_artefacts/${CMAKE_BUILD_TYPE} folder. This complicates building dependencies that produce shared libraries and other artifacts that need to be accessed by the executable, as they now need to build to this subfolder as well. This also means putting the ${CMAKE_BUILD_TYPE} into many paths like CMAKE_RUNTIME_OUTPUT_DIRECTORY (which generator expressions can't always be used), which conflicts with multi-config generators.
• Assembles an .app package before the install phase
• Assembles .app packages by manually creating folders instead of using CPack or MACOSX_BUNDLE
• There are a few more I have run into in the past few months but need to revisit.

I'm starting a new project/refactor now, so I want to try to improve this workflow. I'd like to contribute some configuration options that allow CMake to perform more as it does by convention, but I wanted to open this discussion first to guide the best way to do this. Some ideas:

• Build executables and shared libraries into flat build folder (CMake default)
• Build bundles, packages, and installers using CPack in the install phase

This should also hopefully make some things easier when using CMake outside of IDE environments (like macOS library bundling and signing) as well as add support for new packaging formats (like AppImage).

Thanks,
Perry

What is the expected behaviour?

N/A

Operating systems

Other

What versions of the operating systems?

N/A

Architectures

x86_64, Arm64/aarch64

Stacktrace

Plug-in formats (if applicable)

No response

Plug-in host applications (DAWs) (if applicable)

No response

Testing on the develop branch

The bug is present on the develop branch

Code of Conduct

• I agree to follow the Code of Conduct

[reuk]

• Always builds into non-configurable *_artefacts/${CMAKE_BUILD_TYPE} folder... This also means putting the ${CMAKE_BUILD_TYPE} into many paths like CMAKE_RUNTIME_OUTPUT_DIRECTORY (which generator expressions can't always be used), which conflicts with multi-config generators.

From memory we added the CMAKE_BUILD_TYPE directory because of multi-config generators, to avoid mixing up build outputs when switching configurations. Maybe there are better options that I've overlooked.

• Assembles an .app package before the install phase
• Assembles .app packages by manually creating folders instead of using CPack or MACOSX_BUNDLE

I'm not sure this is true, we definitely do use MACOSX_BUNDLE. What are the specific problems that you're seeing due to the current bundling process?