[xwindow] part 6

[Neumann-A]

[talregev]

@Neumann-A Can you add libxtst?

[Adela0814]

Please fix the conflicts.

[Neumann-A]

@Adela0814 remove requires:author-response.

[vicroms]

I think we should find a better mechanism to mark and replace system dependencies.

In my opinion all packages with X_VCPKG_FORCE_X_LIBRARIES should be empty libraries, and instead of controlling behavior through a triplet variable it should be done through an overlay.

Maybe we could add a new feature to declare system/external dependencies without having to create empty ports?

Something like:

"name": "foo",
"dependencies": [
    {
      "name": "libdrm",
      "external": true,
      "features": [ ... ]
    }
]

Then vcpkg can load overlay for these dependencies or continue without them if none is provided.

[Neumann-A]

In my opinion all packages with X_VCPKG_FORCE_X_LIBRARIES should be empty libraries, and instead of controlling behavior through a triplet variable it should be done through an overlay. Maybe we could add a new feature to declare system/external dependencies without having to create empty ports?

There should be a triplet variable called VCPKG_SYSTEM_PROVIDED_PORTS which is a list of ports which vcpkg treats as system provided and simply skips the install step (just like empty ports). No need to force people to c&p the same empty overlay all day long. Of course there also needs to be the invers. Meaning some json field in the manifest to declare a port (not a dependency) as normally provided by the system with an option to opt out of the behavior. (VCPKG_PROVIDED_SYSTEM_PORTS ?)

[Neumann-A]

The above being said: The current approach has one benefit since you could add additional messaging or testing if the libraries provided by the system actually is provided by the system. So basically the system part of the port could have code (a CMakeLists.txt) which actually tries to check if it can find the library or package required.

[BillyONeal]

Tagging this with reviewed to make sure I consider it with part 8 and 9 which are both also reviewed right now.

[BillyONeal]

In my opinion all packages with X_VCPKG_FORCE_X_LIBRARIES should be empty libraries, and instead of controlling behavior through a triplet variable it should be done through an overlay.

I agree something in this direction is the "correct" thing, but given that all these X things have already been merged with this form, I'm inclined to follow the pattern already followed elsewhere, unless this is an over-my-dead-body issue for you @vicroms?

[BillyONeal]

I discussed this over chat with @vicroms and he pointed out this is different than the other "X" PRs because it leaves these ports completely untested. They become empty on non-Windows, and they have "supports": "!windows" or "supports": "!(windows | osx)"

[Neumann-A]

"X" PRs because it leaves these ports completely untested.

Yeah, I didn't want to force a world rebuild for this one by adding the variable to the linux triplet. I could also comment out the if for testing it once?

[Neumann-A]

@BillyONeal The ports were tested in 4801462f8c9c723c178a2e4ee9de65c883d69f5c: linux/osx green

[Adela0814]

Please fix the conflicts.

[BillyONeal]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 1 pipeline(s).

[BillyONeal]

I discussed this over chat with @vicroms and he pointed out this is different than the other "X" PRs because it leaves these ports completely untested. They become empty on non-Windows, and they have "supports": "!windows" or "supports": "!(windows | osx)"

Sorry, put the tag back because

[JavierMatosD]

Closing this PR on account that nothing here is tested. Feel free to reopen if you still want this and can provide justification.