[gz-*] Rename gz-* ports

[talregev]

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

In the past, we had

• smooth transitions when we upgraded the old names to empty ports which depend on the new name before eventually removing them (example: proj4 -> proj) and
• users stumbling when we immediately removed the old name when add the new name (example: szip -> libaec, cf. [libaec] Build error on x64-windows #43846 et al.).

Just saying.

[talregev]

In the past, we had

• smooth transitions when we upgraded the old names to empty ports which depend on the new name before eventually removing them (example: proj4 -> proj) and
• users stumbling when we immediately removed the old name when add the new name (example: szip -> libaec, cf. [libaec] Build error on x64-windows #43846 et al.).

Just saying.

Thank you for the info. That good practice.
Before I do that, I want to see if I can rename the ports in the first place.
There is an issue when they look for port, because it still looking in port name and number, but no longer available. (only port name).
Do you an idea how to solve that?

[talregev]

Thank you for the info. That good practice. Before I do that, I want to see if I can rename the ports in the first place. There is an issue when they look for port, because it still looking in port name and number, but no longer available. (only port name). Do you an idea how to solve that?

@traversaro Can you help too?

[dg0yt]

Before I do that, I want to see if I can rename the ports in the first place.

You can do that. CI won't complain because it starts from scratch. But classic mode users start with the old ports installed.

There is an issue when they look for port, because it still looking in port name and number, but no longer available. (only port name).

No 100% clear what you mean. But the proposed smooth approach would keep <name><number> in addition to <name>.

[traversaro]

Thank you for the info. That good practice. Before I do that, I want to see if I can rename the ports in the first place. There is an issue when they look for port, because it still looking in port name and number, but no longer available. (only port name). Do you an idea how to solve that?

@traversaro Can you help too?

I am not sure I get what you meant with " There is an issue when they look for port, because it still looking in port name and number, but no longer available. (only port name)."

[talregev]

Sorry I didn't been clear.
From @traversaro comment:
#43265 (comment)

Gazebo packages installing with the package name with the major version. Since I rename the ports as @traversaro suggested:

I think it make perfect sense to drop all the version number suffixes and just package the latest major version of each gz library.

Clearly I didn't do the correct changes, and ci is fail due that it not find the package name with the major version.
My question how to make this refactor in a smooth approach?

[talregev]

I figure it out.

[talregev]

I bring back old ports as @dg0yt suggested:

smooth transitions when we upgraded the old names to empty ports which depend on the new name before eventually removing them

[talregev]

@Mengna-Li Can you review my PR?
The ci is all green.

[JavierMatosD]

@talregev sorry if this is obvious, but can you explain why? -> https://github.com/microsoft/vcpkg/pull/43945/files#diff-bb2e7bd2fecf9e1a5e243d44b7af56ef1b407bd7f02b9b8b80f24a4dfa843c6bR20

Can you get representation from upstream on what the deal is with the version suffix? Should it be there, should it not?

I'm not sure how to check whether or not this is correct. How do we show whether or not this is correct?

[talregev]

sorry if this is obvious, but can you explain why?

Hi @JavierMatosD
I didn't understand what you asking, the link doesn't point to specific question.

Discussion on suffix number was made on this PR:
#43265

Representative from upstream found on this PR @traversaro
He also comment about the suffix number in more detail here:
#43265 (comment)

summary line from what he wrote:

I think it make perfect sense to drop all the version number suffixes and just package the latest major version of each gz library.

Let me know if you need more information.

[JavierMatosD]

@talregev

I didn't understand what you asking, the link doesn't point to specific question.

Specifically, why are you moving everything in ${CURRENT_PACKAGES_DIR}/share/${PORT} into a folder with the version suffix stapled on the end?

file(COPY "${CURRENT_PACKAGES_DIR}/share/${PORT}/" DESTINATION "${CURRENT_PACKAGES_DIR}/share/${PORT}${VERSION_MAJOR}/")

Is the intent for find_package(gz-XxxNnn) working?

[talregev]

Is the intent for find_package(gz-XxxNnn) working?

When using gz-port they have unique find_package function call gz_find_package, and it search the packages with the suffix number. To preserve this behavior and gz packages still need to find themself, I added this line.

[traversaro]

@talregev

I didn't understand what you asking, the link doesn't point to specific question.

Specifically, why are you moving everything in ${CURRENT_PACKAGES_DIR}/share/${PORT} into a folder with the version suffix stapled on the end?

file(COPY "${CURRENT_PACKAGES_DIR}/share/${PORT}/" DESTINATION "${CURRENT_PACKAGES_DIR}/share/${PORT}${VERSION_MAJOR}/")

Is the intent for find_package(gz-XxxNnn) working?

Let's take gz-cmake as an example to be concrete. Even if we moved gz-cmake3 to gz-cmake, the CMake package name of the project is still gz-cmake3, so downstream users need to find it via find_package(gz-cmake3), so its cmake config file need to be installed in a location where find_package can find it accordingly to CMake's find_package search logic, see https://cmake.org/cmake/help/v3.31/command/find_package.html#config-mode-search-procedure . If the CMake config files were installed under gz-cmake, find_package(gz-cmake3) would not work. However, I think do achieve that we can simply change the ignition_modular_library macro in

vcpkg/ports/ignition-modularscripts/vcpkg-port-config.cmake

Line 142 in b69712e

set(DEFAULT_CMAKE_PACKAGE_NAME "ignition-${IML_NAME}${IML_MAJOR_VERSION}")

, there is no need to manually move port directories, as if I remember correctly this will be handled in

vcpkg/ports/ignition-modularscripts/vcpkg-port-config.cmake

Lines 41 to 45 in b69712e

	file(GLOB_RECURSE CMAKE_RELEASE_FILES
	"${CURRENT_PACKAGES_DIR}/lib/cmake/${IML_CMAKE_PACKAGE_NAME}/*")
	file(COPY ${CMAKE_RELEASE_FILES} DESTINATION
	"${CURRENT_PACKAGES_DIR}/share/${IML_CMAKE_PACKAGE_NAME}/")

.

[talregev]

I don't think the suggestion of @traversaro will work out of the box.
vcpkg for fixing PC files and usage files search in share/portname and find_package(portname{major_number}) will search in share/portname{major_number}
@dg0yt What do you think?