[vcpkg/script] get infos from installed ports

[Neumann-A]

some ports require insight into their dependent ports to be configured correctly. One such example is pcl

closes #8269

[Neumann-A]

This (boost) needs to be checked by someone.

[ras0219-msft]

Usually, this is to set macros for the headers or to change searched-for library names -- in both these cases, we should be solving the problem in the dependency (hardcoding the correct macro setting or using an indirection layer like pkg-config/find_package()/??? to get the full list of needed libraries, including transitive dependencies). Do you know what PCL uses it for?

[Neumann-A]

I just checked the variable for boost and it was setting up the find_package call + adding some compile definitions.
At least for plugins which don't use cmake there is no way for the consumer to know if it is static or dynamic and thus needs special handling any way.

Also there are more ports than pcl requiring the information since I can remember saying 'this won't work correctly in a custom triplet a few times in different prs'

[BillyONeal]

I added requires:discussion back so that we look at Neumann-A's reply to Robert

[BillyONeal]

To our understanding, there are 2 expected use cases for this proposal:

• As used here, it's being used to determine which linkage was used in the dependencies, but that should be resolved using pkgconfig or cmake rather than vcpkg making our own convention that must be patched into every port. This may require dependencies to be patched to provide a consistent name that doesn't depend on linkage. See:
  • https://github.com/microsoft/vcpkg/blob/master/docs/maintainers/maintainer-guide.md#choose-either-static-or-shared-binaries
  • The "important caveat" at https://github.com/microsoft/vcpkg/blob/master/docs/maintainers/maintainer-guide.md#do-not-rename-binaries-outside-the-names-given-by-upstream
• For feature detection of dependencies, that should be added as a feature in the consuming port; there should never be a difference in behavior based on features installed in a dependency. Taking advantage of a feature in a dependency should itself be a feature in the dependent which build-depends on the dependency's feature.

We admit that there may be other use cases than enumerated above which might argue to revisit this. However. we believe the above cases are better served as enumerated above.