Override linkage in manifest

[msvetkin]

---

Is your feature request related to a problem? Please describe.
Currently the only way to do per port customization of VCPKG_LIBRARY_LINKAGE is via CMake Macro PORT in a triplet file.
Example:

set(VCPKG_LIBRARY_LINKAGE static)
if(PORT MATCHES "qt5-")
    set(VCPKG_LIBRARY_LINKAGE dynamic)
endif()

That leads to several issues:

1. Any changes of a triplet file cause re-build all dependencies even a package which has not been effected.
   For example if we extend a code above by making fmt package build a dynamic library (if(PORT MATCHES "qt5-|fmt")). It will trigger to rebuild all dependencies, but the only effected one is fmt.
2. If project uses several triplets then we need to copy-paste this information between triplets. It is very easy to forget copy-paste a change and it may lead to be triplets out of sync.
3. If project uses the vcpkg manifest mode then adding / removing a dependency from the manifest will require extra work of checking triplets on a subject of dead code.

Proposed solution
Allow specifying VCPKG_LIBRARY_LINKAGE in a similar manner in the manifest file.

{
  "name": "test-project",
  "version-string": "0.0.1",
  "dependencies": [
    {
      "name": "fmt",
      "linkage": "<static|shared>"
    }
  ]
}

Describe alternatives you've considered
Alternative way would be to include common files between triplets files.

Additional context
#19193

[Neumann-A]

no the correct approach would just be to be more exact about the hashing #19984

[msvetkin]

The suggested approach #19984 does not solve the 2 and 3 point.

[JackBoosY]

@BillyONeal I agree with @Neumann-A , what do you think about?

[Neumann-A]

The suggested approach #19984 does not solve the 2 and 3 point.

2 and 3 are outside vcpkg's responsibility.
About 2: there are ways to avoid copying the same stuff in different triplets (include() but would requires #19984 for correct hashing; also see https://github.com/Neumann-A/my-vcpkg-triplets/blob/c6ad1a8b5153c6ae88c6c4b0a128c69b6c7beb81/x64-win-llvm.cmake#L23-L24 )
About 3: manifest and triplet are disjunct. So dead code in a triplet isn't a thing.

[msvetkin]

I see, thank you for the include example.

A bit different example of point 2.
Let's assume #19984 is resolved and we can use include with correct hash calculation.
It will require to copy paste all triplets and add the include statement to all of them which add some work to do.
Triplet files does not change a lot but still It would be nice if you can override linkage for a library without extra steps.

Alternative approach could be to introduce some VCPKG_CHAINLOAD_TRIPLET_HOST/TARGET which would be sourced right after triplet file. Would it be possible?

[BillyONeal]

In terms of the "oh no, this triggers rebuilds" kind of feedback, I agree with Neumann-A that something similar to the PR they have submitted is probably closest to the correct fix; I know there remain some design concerns there so I'm not sure what kind of timeframe we expect something like that to land.

We are interested in investigating putting more information into the end-user-manifest, not for rebuild avoidance; more just for ease of use; realistically it would be sometime next year before we truly tackle that at the earliest though.

[Osyotr]

Maybe linkage in manifest could act as a default that can be overridden in triplet. This would solve cache invalidation issue before #19984 is merged.

[BillyONeal]

Maybe linkage in manifest could act as a default that can be overridden in triplet. This would solve cache invalidation issue before #19984 is merged.

That is how it already works.

[Osyotr]

That is how it already works.

Huh? Did I miss something?

[msvetkin]

We are interested in investigating putting more information into the end-user-manifest, not for rebuild avoidance; more just for ease of use; realistically it would be sometime next year before we truly tackle that at the earliest though.

The prosed extension of manifest looks like simplification of use in my opinion.
In case linkage configuration users does not need to:

1. manually copy triplets and maintain them
2. share linkage configuration across triplets
3. platforms conditions allows to easily change linkage configuration

We are interested in investigating putting more information into the end-user-manifest, not for rebuild avoidance; more just for ease of use; realistically it would be sometime next year before we truly tackle that at the earliest though.

Could you share your thoughts on what kind of information you are looking into?

[BillyONeal]

That is how it already works.

Huh? Did I miss something?

Triplets are the overriding mechanism. This request is to let manifests be an overriding mechanism too.

[BillyONeal]

We are interested in investigating putting more information into the end-user-manifest, not for rebuild avoidance; more just for ease of use; realistically it would be sometime next year before we truly tackle that at the earliest though.

Could you share your thoughts on what kind of information you are looking into?

I don't have concrete "this is a spec for what we will do" to show you right now; I'm only saying that the feedback of "it sucks to have to write a triplet to customize a lot of these things" is feedback we have been getting and understand.

[github-actions]

This is an automated message. Per our repo policy, stale issues get closed if there has been no activity in the past 180 days. The issue will be automatically closed in 14 days. If you wish to keep this issue open, please add a new comment.

[traversebitree]

I think it is necessary to specify the link type of each library by override in manifest mode.