[fastrtps] Fixes missing fast-discovery-serverd-1.0.1.exe

[Cheney-W]

Fixes #39375

Usage test passed with x64-windows

• 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.

[dg0yt]

I think the issue wasn't properly understood.

This port doesn't use the regular maintainer function vcpkg_copy_tools which might be the entire reason for the reported issue: vcpkg_cmake_config_fixup is expecting a different tool location.

But there is also "debug" aspect: @BillyONeal @ras0219-msft After the dbus-daemon discussion, can you please double check and advise for this PR:

• Port to vcpkg_copy_tools?
• Keep debug executables?
• Put the debug executable to /debug/tools/<port>?

I do understand that vcpkg_copy_tools becomes clumsy to use when there are scripts in addition to binaries. But improving things should be left to the community alone.

[BillyONeal]

But there is also "debug" aspect: @BillyONeal @ras0219-msft After the dbus-daemon discussion, can you please double check and advise for this PR:

Tagged to discuss this

[BillyONeal]

@Cheney-W It seems like the bug is that the CMake targets are referring to the debug tool rather than referring to the release tool. Alternately, the right fix might be to remove the references from the targets entirely.

[dg0yt]

The debug tool seems to have a slightly different filename. That's why the default behavior of vcpkg_cmake_config_fixup isn't sufficient. (It maps everything to /tools/<port> but it doesn't adjust filenames.)

Whether the port needs to keep the debug tool, and where, are separate questions.

[Cheney-W]

If we want to remove the reference to fast-discovery-server-targets, we need to delete this content:
https://github.com/eProsima/Fast-DDS/blob/d3ca40cbce231c4bdb4fc88a4b3911afaaae4f6f/cmake/packaging/Config.cmake.in#L92
@INCLUDE_FASTDDS_TARGETS@
However, this seems to go against the intention of the upstream.

From below code:
https://github.com/eProsima/Fast-DDS/blob/d3ca40cbce231c4bdb4fc88a4b3911afaaae4f6f/tools/fds/CMakeLists.txt#L72
set_target_properties(${PROJECT_NAME} PROPERTIES DEBUG_POSTFIX d-${PROJECT_VERSION})
it appears that the upstream intentionally differentiates the tool names generated in debug and release modes. Therefore, my original plan was just to place the tools generated in debug mode under tool\debug\bin.

[zhangzhen5729]

I reinstalled vcpkg and executed git pull and vcpkg update to install fastrtps2.14.0, but the issue still persists and has not been fixed

[dg0yt]

I still think this port needs better restructuring, for canonical fixup. Not another variant of debug tool installation pattern unless applying for the vcpkg tool installation layout hall of shame.
And there is also #39954.

[Cheney-W]

If we remove the d suffix from below codes:
https://github.com/eProsima/Fast-DDS/blob/d3ca40cbce231c4bdb4fc88a4b3911afaaae4f6f/tools/fds/CMakeLists.txt#L72
set_target_properties(${PROJECT_NAME} PROPERTIES DEBUG_POSTFIX d-${PROJECT_VERSION})
allowing this port to generate tool files with the same name in both debug and release builds, do you think this approach would work?
This method is actually a common practice used by most ports generating tools in vcpkg, but it does go against the original upstream design here. I'm not sure if this change is appropriate, but it is certainly the simplest solution.