Invalid `CMakePresets.json` path used as part of build

Question

Invalid `CMakePresets.json` path used as part of build

cleak opened this issue 2 months ago · comments

Describe the bug
The CMake configuration written out when creating a new project appears incorrect. This makes builds in VS Code difficult as it fails to find the correct build presets (such as profile) and doesn't allow standard presets since they've been overridden.

For a project Foo in C:/MyProjects/Foo, the chain of CMakePresets.json goes like this:

C:/MyProjects/Foo/CMakePresets.json is found and loaded. This contains:

{
    "version": 4,
    "cmakeMinimumRequired": {
        "major": 3,
        "minor": 23,
        "patch": 0
    },
    "include": [
        "user/cmake/engine/CMakePresets.json"
    ]
}

C:/MyProjects/Foo/user/cmake/engine/CMakePresets.json is parsed, which contains:

{
    "version": 4,
    "cmakeMinimumRequired": {
        "major": 3,
        "minor": 23,
        "patch": 0
    },
    "include": [
        "C:/O3DE/23.10.2/CMakePresets.json"
    ]
}

Parsing is attempted on C:/O3DE/23.10.2/CMakePresets.json, but it doesn't exist and so no presets are loaded.

It seems like C:/O3DE/23.10.2/CMakePresets.json should actually be C:/O3DE/23.10.2/cmake/Platform/Windows/CMakePresets.json. It looks like this particular line is written out from cmake.py line 73. There's not an obvious way to pull the target build platform string in this script, otherwise I'd submit a PR for it.

Assets required
None

Steps to reproduce

Create a new empty project.
Open that project is VS Code (or just look at its CMakePresets.json.
Follow the chain of CMakePresets.json includes until you find one that doesn't exist.

Expected behavior
CMakePresets.json should point to a file that exists.

Actual behavior
CMakePresets.json doesn't exist at the specified location.

Screenshots/Video
N/A

Found in Branch
Release 23.10.2. It appears to to still be in master as of today.

Commit ID from o3de/o3de Repository
8749168e1f79263395b945f1623b7314003bf366 (latest in master as of right now)

Desktop/Device (please complete the following information):

Device: PC
OS: Windows
Version 11
CPU AMD 7950x3D
GPU Nvidia RTX 4090
Memory 64GB

Additional context
N/A

lemonade-dm · Answer 1 · Thu Apr 18 2024 00:15:20 GMT+0800 (China Standard Time)

This has been fixed in the o3de development branch as part of PR #17594.
@o3de/sig-release we should merge this change into the next 23.10.3 point release.

Caleb Leak · Answer 2 · Wed Apr 24 2024 11:36:14 GMT+0800 (China Standard Time)

Thanks! I gave the development branch a try and it works, but with some limitations - there's no option to change between debug, profile, and release unfortunately. Trying to do this with my own CMakePresets.json below fails for all but profile. I'm not sure if this is a limitation in VS Code's CMake plugin or if it's something else. It'd be great to have someone from the team try VS Code on Windows. I'm happy doing a manual configuration or command line build, but it needs to integrate with Intellisense which probably requires going through VS Code's CMake Plugin.

For debug mode I'm getting the following output:

Build

[main] Building folder: FixedCmakePresets_01 
[build] Starting build
[build] Build finished with exit code -1
[cmake] -- Generating done (4.9s)
[cmake] CMake Warning:
[cmake]   Manually-specified variables were not used by the project:
[cmake] 
[cmake]     CMAKE_BUILD_TYPE
[cmake] 
[cmake] 
[cmake] -- Build files have been written to: C:/Projects/O3DE/FixedCmakePresets_01/build/windows
[cpptools] The build configurations generated do not contain the active build configuration. Using "profile" for CMAKE_BUILD_TYPE instead of "debug" to ensure that IntelliSense configurations can be found

CMakePresets.json

{
    "version": 4,
    "cmakeMinimumRequired": {
        "major": 3,
        "minor": 23,
        "patch": 0
    },
    "include": [
        "cmake/Platform/Windows/CMakePresets.json"
    ],
    "configurePresets": [
        {
            "name": "windows-default-profile",
            "displayName": "[Profile] Windows",
            "description": "Default Windows in Profile Mode",
            "inherits": [
                "windows-default",
                "profile"
            ]
        },
        {
            "name": "windows-default-debug",
            "displayName": "[Debug] Windows",
            "description": "Default Windows in Debug Mode",
            "inherits": [
                "windows-default",
                "debug"
            ]
        },
        {
            "name": "windows-default-release",
            "displayName": "[Release] Windows",
            "description": "Default Windows in Release Mode",
            "inherits": [
                "windows-default",
                "release"
            ]
        }
    ],
    "buildPresets": [
        {
            "name": "BuildWindowsProfile",
            "description": "Profile Windows",
            "configurePreset": "windows-default-profile",
            "configuration": "profile"
        },
        {
            "name": "BuildWindowsDebug",
            "description": "Debug Windows",
            "configurePreset": "windows-default-debug",
            "configuration": "debug"
        },
        {
            "name": "BuildWindowsRelease",
            "description": "Release Windows",
            "configurePreset": "windows-default-release",
            "configuration": "release"
        }
    ]
}

lemonade-dm · Answer 3 · Thu Apr 25 2024 00:14:39 GMT+0800 (China Standard Time)

Thanks! I gave the development branch a try and it works, but with some limitations - there's no option to change between debug, profile, and release unfortunately. Trying to do this with my own CMakePresets.json below fails for all but profile. I'm not sure if this is a limitation in VS Code's CMake plugin or if it's something else. It'd be great to have someone from the team try VS Code on Windows. I'm happy doing a manual configuration or command line build, but it needs to integrate with Intellisense which probably requires going through VS Code's CMake Plugin.

For debug mode I'm getting the following output:

Build

[main] Building folder: FixedCmakePresets_01 
[build] Starting build
[build] Build finished with exit code -1
[cmake] -- Generating done (4.9s)
[cmake] CMake Warning:
[cmake]   Manually-specified variables were not used by the project:
[cmake] 
[cmake]     CMAKE_BUILD_TYPE
[cmake] 
[cmake] 
[cmake] -- Build files have been written to: C:/Projects/O3DE/FixedCmakePresets_01/build/windows
[cpptools] The build configurations generated do not contain the active build configuration. Using "profile" for CMAKE_BUILD_TYPE instead of "debug" to ensure that IntelliSense configurations can be found

CMakePresets.json

{
    "version": 4,
    "cmakeMinimumRequired": {
        "major": 3,
        "minor": 23,
        "patch": 0
    },
    "include": [
        "cmake/Platform/Windows/CMakePresets.json"
    ],
    "configurePresets": [
        {
            "name": "windows-default-profile",
            "displayName": "[Profile] Windows",
            "description": "Default Windows in Profile Mode",
            "inherits": [
                "windows-default",
                "profile"
            ]
        },
        {
            "name": "windows-default-debug",
            "displayName": "[Debug] Windows",
            "description": "Default Windows in Debug Mode",
            "inherits": [
                "windows-default",
                "debug"
            ]
        },
        {
            "name": "windows-default-release",
            "displayName": "[Release] Windows",
            "description": "Default Windows in Release Mode",
            "inherits": [
                "windows-default",
                "release"
            ]
        }
    ],
    "buildPresets": [
        {
            "name": "BuildWindowsProfile",
            "description": "Profile Windows",
            "configurePreset": "windows-default-profile",
            "configuration": "profile"
        },
        {
            "name": "BuildWindowsDebug",
            "description": "Debug Windows",
            "configurePreset": "windows-default-debug",
            "configuration": "debug"
        },
        {
            "name": "BuildWindowsRelease",
            "description": "Release Windows",
            "configurePreset": "windows-default-release",
            "configuration": "release"
        }
    ]
}

Well depending on the Generator used for generation of a CMake project, the CMAKE_BUILD_TYPE option is not needed during configuration.
Using the Ninja Multi-Config, Visual Studio 17 or Xcode generator creates a project with the three build configurations that O3DE specifies for theCMAKE_CONFIGURATION_TYPES cache variable.

The CMake build configurations available in an installer build is based on the configs that are built as part of the installer.
Currently in the 23.10.2 point-release, it only contains the non-monolithic profile config and the monolithic release config.
The debug config is NOT available in the installer. Therefore debug builds cannot be made using the O3DE engine from an installer.

The O3DE development branch contains access to all 3 build configurations of "debug", "profile" and "release", and the CMake VS code plugin will try to configure using the Visual Studio Generator if Visual Studio is installed on the operating system. Otherwise I believe it will try to configure using NMake.
Now because Visual Studio is the default generator, there is no need to specify the CMAKE_BUILD_TYPE option when configuring.
However the Build Presets for the CMake presets, requires the build configuration to be specified as part of the "configuration" field otherwise it will default to profile if that configuration is available.

So far the build configurations specified in the per-platform CMakePresets.json such as the ones at
Windows - CMakePreset.json doesn't specify the build config currently.

Because of that it only attempts to build the "profile" config.

Adding the build presets for each would result in a combinatorics increase in permutations added to each per Platform CMakePresets.json and CMake doesn't provide a great solution currently to prevent needing to have a large amount of build presets.

For example as part of the build presets for Windows we could add permutations to default build each if the 3 configurations for all, ediitor, assetprocessor, etc...

        {
            "name": "windows-editor-debug",
            "displayName": "Windows Editor debug",
            "description": "Builds the Editor application for Windows for debug config",
            "configurePreset": "windows-default",
            "configuration": "debug",
            "inherits": [
                "windows-editor"
            ]
        },
        {
            "name": "windows-editor-profile",
            "displayName": "Windows Editor profile",
            "description": "Builds the Editor application for Windows for profile config",
            "configurePreset": "windows-default",
            "configuration": "profile",
            "inherits": [
                "windows-editor"
            ]
        },
        {
            "name": "windows-editor-release",
            "displayName": "Windows Editor release",
            "description": "Builds the Editor application for Windows for release",
            "configurePreset": "windows-default",
            "configuration": "release",
            "inherits": [
                "windows-editor"
            ]
        },

However adding a build preset with the "configuration" field that would need to be done for each set of build targets that is desired to be built.

So windows-default build preset target would also need to add 3 per "configuration" presets for it as well, as the other build presets in the Windows/CMakePresets.json file.

That only applies for the Windows CMakePresets.json file, while the other platforms of Linux, Android, MacOS and iOS would also need those changes as well.

Finally CMake "buildPresets" has a big limitation, that that they are associated with a single "configurePreset".
Therefore VS Code will only show the "build presets" for the single configure preset that was used to configure.

For example if a user on Windows decided to use the windows-no-unity in VS code to configure their project, then the build presets that uses the with windows-default configure preset would not be used.

References:
Ticket about preset explosion: https://gitlab.kitware.com/cmake/cmake/-/issues/22538

Caleb Leak · Answer 4 · Sun Apr 28 2024 03:54:53 GMT+0800 (China Standard Time)

Using the Ninja Multi-Config, Visual Studio 17 or Xcode generator creates a project with the three build configurations that O3DE specifies for theCMAKE_CONFIGURATION_TYPES cache variable.

Unfortunately Visual Studio 17 and Ninja Multi-Config both only generate profile build types. Is there a way to specify generating multiple build types?

lemonade-dm · Answer 5 · Sun Apr 28 2024 07:45:58 GMT+0800 (China Standard Time)

Using the Ninja Multi-Config, Visual Studio 17 or Xcode generator creates a project with the three build configurations that O3DE specifies for theCMAKE_CONFIGURATION_TYPES cache variable.

Unfortunately Visual Studio 17 and Ninja Multi-Config both only generate profile build types. Is there a way to specify generating multiple build types?

It sounds like you are using the 23.10.2 installer build of O3DE.

The installer build only contains the profile configuration when building in a non-monolithic mode which is the default mode when configuring CMake for O3DE.
The release build configuration is available when building in monolithic however that requires configuring using the CMake cache variable of LY_MONOLITHIC_GAME=1.
There are CMake presets available that sets that cache variable option, however monolithic builds only output the launcher application since it is meant to build artifacts that are provided to the end user.

Finally the debug build configuration is not available in the installer at all. That is to safe space with the installed size of O3DE, as that would add upwards of 20GiB of artifacts to the installer.

The targeted user base for installer are designers and enthusiast that that wants to quickly get up in running using the O3DE Editor and launcher without needing the ability to have accurate the symbol information that the debug configuration provides.

Because the installer only contains the pre-built static/shared and application libraries for the profile configuration, we purposely only expose the build configuration the user of the O3DE SDK can use.

lemonade-dm · Answer 6 · Sun Apr 28 2024 08:03:28 GMT+0800 (China Standard Time)

SDK Engine

For all of the above that I typed in my previous comment only applies to the installer that the O3DE Jenkins server builds.
The configuration for building the installer is actually located in source control in each platform specific build_config.json file located within the following folder: https://github.com/o3de/o3de/tree/development/scripts/build/Platform

For example on Windowos we use a Jenkins pipeline step called installer_pipe to build the "profile non-monolithic" and "release monolithic" configurations for O3DE into an installer layout folder and then use CPack with WiX to package an installer from that folder.

It is actually possible for individual users to create their own "install layout" folder as well as an installer locally on their machine using the ci_build.py script.

However in most cases only an "install layout" is needed, which is just a folder containing the artifacts needed to run O3DE portable fashion. There are instructions for creating a pre-built O3DE SDK on the official doc page here.

Source Engine

Now all of the restrictions of only having the profile build configuration in the installer does not apply when building O3DE from source code.
As the engine source code is available all three configurations are available when configuring using CMake.
The guide for Building for Windows details building for source: https://docs.o3de.org/docs/welcome-guide/setup/setup-from-github/building-windows/#build-type