[darknet, openmama, gherkin-c, libevent] Conflicts when installing headers

[vicroms]

The following header conflics occur when trying to install these libraries in the presence of each other.

Header file	Conflicting Ports
include/list.h	darknet & openmama
include/parser.h	darknet & gherkin-c
include/event.h	gherkin-c & libevent

Due to user expectation, we want to preserve upstream include paths as much as possible.
However, when these file conflicts happen, a decision must be made by the vcpkg team on which library will be "blessed" by our CI tests.

For example, in the case of libevent, due to it's long history, it takes precedence in claiming ownership of include/event.h.

The logical solution would be to move the installation path to these packages to their own subfolders, e.g.: include/darknet/list.h, include/openmama/list.h. And the easiest way to do this, would be doing this within the portfile. However, the right way would be to submit a request for these changes to be made upstream.

[vicroms]

@cenit would it be OK to move darknet's headers to their own subfolder, or would this break too many consuming projects?

[cenit]

I think it’s feasible. Let me try it upstream. It should be quick.
Darknet doesn’t have a long history used as a library, especially in c++ (most users exploit the Python bindings). For a long time the source code of the executable itself was hacked and adapted to requirements, so I don’t see a huge uproar from this request

[Fleischner]

Is it correct that vcpkg integrate only adds the vcpkg header base directory?

In this case. Does the CI test also include an check over all headers that verifies that #incudes are reachable either from this base directory or from the local header directory? Because sometimes I need to fix paths. The problem is that this shows up only during usage. E.g in magnum port a couple of days ago (some bullet integration and Khronos headers)

[myd7349]

#6532

[Rastaban]

gherkin-c is currently disabled in the CI tests, and darknet have moved into its headers into its own sub-directory. I am closing the issue as resolved (although there are other ports not listed in this issue that still conflict)