[bgfx]: Update to 1.127.8725.469

[bwrsandman]

This new version of bgfx removes support for D3D9 and WebGPU.
The package has been updated so tools better support cross compilation by being able to generate a config cmake file which is installed linking the proper host tools path. Prior to this, it assumed that all hosts were x64 which prevented cross compiling from apple sillicon and raspberry pis for example.

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

[bwrsandman]

Causing an issue with the tests because of Absolute paths in D:\p\bgfx_x86-windows\share\bgfx\bgfxConfig.cmake

I was hoping I could use CURRENT_HOST_INSTALLED_DIR to my advantage for this file which wraps a compilation tool. This tool is used for intermediate build steps inside of cmake. For example, compiling a graphics shader to a header and depending on that shader for compilation of a binary.

# If cross compiling, we need a host-compatible version of shaderc to compile shaders
macro(_bgfx_crosscompile_use_host_tool TOOL_NAME)
  if(NOT TARGET bgfx::${TOOL_NAME})
    find_program(
      ${TOOL_NAME}_EXECUTABLE
      NAMES bgfx-${TOOL_NAME} ${TOOL_NAME}
      # =====> <=====
      PATHS
      # When installed globally, it's easy to find
      /usr/bin
      # When installed as part of vcpkg, I need a way to find the program at config time
      /absolute/path/to/vcpkg_installed/x64-linux/tools/bgfx
      # Previously, I would use CMAKE_CURRENT_SOURCE_DIR but I cannot apply the triplet in this
      # context, so I have to list all the possible triplets. Assuming x64 causes issues with apple sillicon
      ${CMAKE_CURRENT_SOURCE_DIR}/vcpkg/packages/bgfx_x64-osx/tools/bgfx
      # =====> <=====
    )
    add_executable(bgfx::${TOOL_NAME} IMPORTED)
    set_target_properties(bgfx::${TOOL_NAME} PROPERTIES IMPORTED_LOCATION "${${TOOL_NAME}_EXECUTABLE}")
  endif()
endmacro()

_bgfx_crosscompile_use_host_tool(bin2c)
_bgfx_crosscompile_use_host_tool(texturec)
_bgfx_crosscompile_use_host_tool(shaderc)
_bgfx_crosscompile_use_host_tool(texturev)
_bgfx_crosscompile_use_host_tool(geometryv)

# If bgfx.cmake was compiled without tools or cross compiled without host having tools,
# then don't provide helper functions
if(TARGET bgfx::bin2c)
    # _bgfx_bin2c_parse(
    #   INPUT_FILE filename
    #   OUTPUT_FILE filename
    #   ARRAY_NAME name
    # )
    # Usage: bin2c -f <in> -o <out> -n <name>
    function(_bgfx_bin2c_parse ARG_OUT)
        set(options "")
        set(oneValueArgs INPUT_FILE;OUTPUT_FILE;ARRAY_NAME)
        set(multiValueArgs "")
        cmake_parse_arguments(ARG "${options}" "${oneValueArgs}" "${multiValueArgs}" "${ARGN}")
        set(CLI "")

        # -f
        if(ARG_INPUT_FILE)
            list(APPEND CLI "-f" "${ARG_INPUT_FILE}")
        else()
            message(SEND_ERROR "Call to _bgfx_bin2c_parse() must have an INPUT_FILE")
        endif()

        # -o
        if(ARG_OUTPUT_FILE)
            list(APPEND CLI "-o" "${ARG_OUTPUT_FILE}")
        else()
            message(SEND_ERROR "Call to _bgfx_bin2c_parse() must have an OUTPUT_FILE")
        endif()

        # -n
        if(ARG_ARRAY_NAME)
            list(APPEND CLI "-n" "${ARG_ARRAY_NAME}")
        else()
            message(SEND_ERROR "Call to _bgfx_bin2c_parse() must have an ARRAY_NAME")
        endif()

        set(${ARG_OUT} ${CLI} PARENT_SCOPE)
    endfunction()

    # bgfx_compile_binary_to_header(
    #   INPUT_FILE filename
    #   OUTPUT_FILE filename
    #   ARRAY_NAME name
    # )
    #
    function(bgfx_compile_binary_to_header)
        set(options "")
        set(oneValueArgs INPUT_FILE;OUTPUT_FILE;ARRAY_NAME)
        set(multiValueArgs "")
        cmake_parse_arguments(ARG "${options}" "${oneValueArgs}" "${multiValueArgs}" "${ARGN}")
        _bgfx_bin2c_parse(
            CLI
            INPUT_FILE ${ARG_INPUT_FILE}
            OUTPUT_FILE ${ARG_OUTPUT_FILE}
            ARRAY_NAME ${ARG_ARRAY_NAME}
        )
        add_custom_command(
            OUTPUT ${ARG_OUTPUT_FILE} #
            COMMAND bgfx::bin2c ${CLI} #
            MAIN_DEPENDENCY ${ARG_INPUT_FILE} #
        )
    endfunction()
endif()

[dg0yt]

-DVCPKG_CURRENT_HOST_INSTALLED_DIR

Better do not adapt your project to vcpkg or any other package manager, but adopt or implement a generic interface, and use that in the portfile.

		find_program(
			${TOOL_NAME}_EXECUTABLE
			NAMES bgfx-${TOOL_NAME} ${TOOL_NAME}
			PATHS /usr/bin 
                        /absolute/path/to/vcpkg_installed/x64-linux/tools/bgfx # <================
		)

If the vcpkg CMake toolchain is configured with VCPKG_HOST_TRIPLET, it will simply add the host triplet tool paths to CMAKE_PROGRAM_PATH. So a plain

find_program(${TOOL_NAME}_EXECUTABLE NAMES bgfx-${TOOL_NAME} ${TOOL_NAME} NAMES_PER_DIR)

shoud be enough.

When building ports, vcpkg doesn't pass VCPKG_HOST_TRIPLET unfortunately. You have to add it explicitly to the OPTIONS, -DVCPKG_HOST_TRIPLET=${HOST_TRIPLET}.

[bwrsandman]

I will test this:

If the vcpkg CMake toolchain is configured with VCPKG_HOST_TRIPLET, it will simply add the host triplet tool paths to CMAKE_PROGRAM_PATH

But if that's true, I don't quite understand the bit about VCPKG_HOST_TRIPLET. Is that if for some reason, I need the triplet?

The latest push I made, makes use of HOST_TRIPLET this but if what you say is true, I don't even need to do that, correct?

[dg0yt]

The point is to get the HOST_TRIPLETvalue from script mode (portfile.cmake) to VCPKG_HOST_TRIPLET in project mode (CMakeLists.txt) where it is used by the vcpkg.cmake toolchain.
And don't ask me why this isn't standard. Maybe to avoid turning some Windows builds into vcpkg cross builds, to workaround missing proper host tool dependencies...

[bwrsandman]

It sounds like with your proposed solution, I now need to determine myself in any project CMakeLists.txt what my host triplet is, without being able to leverage vcpkg's own scripts. All of this before the vcpkg toolchain is loaded?

This is not very portable since I need a different cmake preset for each platform whereas before, I could just use ninja multi config and VCPKG_CHAINLOAD_TOOLCHAIN_FILE.

Compare this to using

-DADDITIONAL_TOOL_PATH="\\\$\$\{CMAKE_CURRENT_LIST_DIR}/../../../${HOST_TRIPLET}/tools/bgfx"

to add to the PATH something looking like ${CMAKE_CURRENT_LIST_DIR}/../../../arm64-osx/tools/bgfx
I understand that my above suggestion could have issues with moving packages to different platforms but at least for a majority of usecases of cross compilation, this would work.

[dg0yt]

Yes, not initializing the host triplet is troublesome. Cf. #25529 for a draft solution and discussion.

[bwrsandman]

Thank you for the context.
This task looks a long way off. I'm not sure what Making this work on MSBuild means but if I can do anything to help, I'd be happy to try my hand at it.

In the meantime, what do you think about my ADDITIONAL_TOOL_PATH solution with a comment link to #25529 ?

[dg0yt]

In the meantime, what do you think about my ADDITIONAL_TOOL_PATH solution with a comment link to #25529 ?

What does it add over CMAKE_PROGRAM_PATH?
And if you need to use HOST_TRIPLET in the value, you can just set VCPKG_HOST_TRIPLET.
But maybe I misunderstood the intented pattern.

${CMAKE_CURRENT_LIST_DIR}/../../../arm64-osx/tools/bgfx

This is a pattern that some ports burn into installed config files. It is relocatable, and it works for native and for cross builds.

[bwrsandman]

For an example manifest mode project which uses bgfx, I will refer to openblack because it's my own usecase.

In bgfx.cmake there is a helper cmake script which wraps tools into cmake commands. This way you can set-up a compilation chain which uses these tools to convert binaries or shaders into headers. This is useful for distributing only a binary and not having to haul assets around once built and having to load them at runtime with filesystem access.

The helper script works well except for when cross-compiling, you can't run the tools. This is why we're leveraging the host-only features of vcpkg. bgfx is currently assuming your host will be x64. I want that to be more dynamic.

At bgfx time config time, VCPKG_HOST_TRIPLET is available but at openblack's config time, VCPKG_HOST_TRIPLET is unavailable unless I set it. Setting VCPKG_HOST_TRIPLET manually for openblack is not an attractive solution, it requires setting it in too many places. With #25529 this would be a different story.

The reason for this is that the shader compilation etc happens at the openblack build time and the steps are set at openblack's configuration time. This is a point in time that VCPKG_HOST_TRIPLET is unavailable.

bgfx already has a templated config file to pass to openblack. For this to work, once the template is copied and the @ variables are expanded, the paths must be set. Importantly, this is HOST_TRIPLET.

I'm proposing something like this.

# cmake/Config.cmake.in
find_program(
        ${TOOL_NAME}_EXECUTABLE
        NAMES bgfx-${TOOL_NAME} ${TOOL_NAME}
        PATHS @ADDITIONAL_TOOL_PATHS@ /usr/bin
)

I cannot set the full package path, because it's not portable and there is already a test for absolute paths here.
Once substituted, the template will look like this (HOST_TRIPLET=arm64-osx).

ADDITIONAL_TOOL_PATHS=\\\$\$\{CMAKE_CURRENT_LIST_DIR}/../../../${HOST_TRIPLET}/tools/bgfx \\\$\$\{CMAKE_CURRENT_LIST_DIR}/../../../bgfx_${HOST_TRIPLET}/tools/bgfx

# cmake/Config.cmake.in
find_program(
        ${TOOL_NAME}_EXECUTABLE
        NAMES bgfx-${TOOL_NAME} ${TOOL_NAME}
        PATHS
              # For manifest mode
              ${CMAKE_CURRENT_LIST_DIR}/../../../arm64-osx/tools/bgfx
              # For non-manifest mode
              ${CMAKE_CURRENT_LIST_DIR}/../../../bgfx_arm64-osx/tools/bgfx
              /usr/bin
)

Unless I missed something, I can't set CMAKE_PROGRAM_PATH for openblack's config without putting a lot of vcpkg-specific in bgfx's cmake and HOST_TRIPLET can trickle down but only if I set it in the template.

With #25529, as I understand it, the CMAKE_PROGRAM_PATH would include the host tools path without needing to us to set VCPKG_HOST_TRIPLET at openblack's config time. This would allow us to remote PATHS from the config template altogether!

[JonLiu1993]

Tested usage successfully by bgfx[*]:x64-windows:

bgfx provides CMake targets:

  # this is heuristically generated, and may not be correct
  find_package(bgfx CONFIG REQUIRED)
  # note: 1 additional targets are not displayed.
  target_link_libraries(main PRIVATE bgfx::bx bgfx::bgfx bgfx::bimg bgfx::bimg_decode)