[zeroc-ice] Revise features and build; Wrap FindIce.cmake

[dg0yt]

zeroc-ice

• Build C++98 components also for windows, but move C++98 libs to manual-link.
  (Note: some C++98 libs were already built in the past because they are used by tools.)
• Align (libs) feature names with upstream's component names.
  (Deprecated feature names should be remove with a future update.)
• Add IcePatch2 feature.
• Extend default features list to cover all components, similar to official binary distribution.
• Use vcpkg_configure_make/vcpkg_install_make pattern for non-windows builds, reduce patching.
• Improve cross-build support by using host slice2cpp.
• Add wrapper for FindIce.cmake, fixes [zeroc-ice] x64-windows-static-md library not found  #33589.
  (Tested in CI for COMPONENTS Ice Ice++11).

Tested with vcpkg test-features --triplet x64-linux-dynamic zeroc-ice (microsoft/vcpkg-tool#802).

(zeroc-ice-)mcpp

• Add "zeroc-ice-" prefix to the name because it is an unofficial fork.
• Minor changes to the build.

cmake-user (CI test port)

• Add facility to use CI test cmake config provided by actual ports.

[dg0yt]

https://doc.zeroc.com/ice/3.7/release-notes/supported-platforms-for-ice-3-7-9#id-.SupportedPlatformsforIce3.7.9v3.7-IceforC++

[dg0yt]

Port mcpp didn't use the official upstream but a simplified source from zeroc-ice. This PR move the port implementation to zeroc-ice-mcpp. The mcpp name could be delisted.

[dg0yt]

• Align (libs) feature names with upstream's component names.

TBH I would prefer a radical simplification of the feature interface, e.g.
core: C++98 API libs and slice2cpp
c++11: C++11 API libs. (Extra config in non-windows build.)
tools: all tools (shared only)

C++98 API libs are needed for almost all tools. That's why it makes sense to have them in core.
For the users' transition, the old now-deprecated features would depend on c++11 to pull in what was installed before.

[dg0yt]

Waiting for #33967 to be merged first, unblocking arm windows CI.

[dg0yt]

Waiting for #34085 to fix baseline regression.

[BillyONeal]

• Align (libs) feature names with upstream's component names.

TBH I would prefer a radical simplification of the feature interface, e.g. core: C++98 API libs and slice2cpp c++11: C++11 API libs. (Extra config in non-windows build.) tools: all tools (shared only)

C++98 API libs are needed for almost all tools. That's why it makes sense to have them in core. For the users' transition, the old now-deprecated features would depend on c++11 to pull in what was installed before.

This is really a 'what do users of this thing' expect question. Tagging folks who have contributed to this port before.

@bold84 @jvbsl What do you think of @dg0yt 's proposal?

[bold84]

Everything @dg0yt proposed makes sense. 👍

[jvbsl]

@dg0yt First of all sorry for not answering earlier, the GitHub notification must have slipped by me, cause of the flood of notifications ^^

@bold84 thanks for tagging;)

Do I understand correctly that you mean that the c++98 libs are always built and installed, whereas the c++11 bindings and slice2cppare optional features(meaning if I select it, all libraries will be built using c++11?)
So that there would be no granular control of which specific libraries to install?

If so that would be completely fine by me. To be honest I changed the project I'm working on to use the c++11 bindings just because zeroc-ice vcpkg only provided those. I'm not even sure if the maintainers would be comfortable with such a big change^^
So it would be even better to have that option.

Thank you again @dg0yt for all your work it's creatly appreciated

[dg0yt]

Do I understand correctly that you mean that the c++98 libs are always built and installed, whereas the c++11 bindings and slice2cpp are optional features(meaning if I select it, all libraries will be built using c++11?)
So that there would be no granular control of which specific libraries to install?

slip2cpp should always be built (core) for native targets. (It is a tool which runs on the host.)

Upstream provide a complete SDK, so this is what I would expect from the default installation.
Why would users opt out of individual libraries?
For this port, the specific libraries have hardly any impact on external dependencies.
And AFAICS they also have no fine-grain impact on build times.
C++98 libs are always used for most tools ATM.

To be honest I changed the project I'm working on to use the c++11 bindings just because zeroc-ice vcpkg only provided those.

IMO this is a kind of change which the default installation of a vcpkg port shouldn't require.

[dg0yt]

I will go ahead with the proposed change to the feature interface, so that we can see the impact on what must be maintained in vcpkg.

[BillyONeal]

I will go ahead with the proposed change to the feature interface, so that we can see the impact on what must be maintained in vcpkg.

Are you saying you want to make changes or that you intend to do those in a subsequent PR?

[dg0yt]

I want to make the changes first.

[jvbsl]

May I know what the current state of this draft is and whether there is something I could help with?

[dg0yt]

I hope I can move this to ready-to-review again soon.

[jvbsl]

Hey @dg0yt,
Don't want to be pushy and I of course know that all this is on a voluntary basis, but I hope you have just forgotten about this, and a small reminder would get it in your mind again :D
Apart from that I looked where the merge conflichts come from and rebased everything here:
https://github.com/jvbsl/vcpkg/tree/zeroc-ice
But it was just one merge conflict in scripts/ci.baseline.txt which was really easily resolved. So no need to use my branch as a basis. Just wanted to inform you that rebasing here is fortunately really easy(as I personally dislike fixing conflicts^^).
My message could perhaps sound entitled, but it is really not meant in that way. I would just really like to have this merged and if there is anything I could help you with(could also be on another topic or project) just do tell
But thank you again with all your help so far(also on other vcpkg topics)

Edit: should I perhaps look why the windows build fail?