[X Window System] add libraries for the x window systems

[Neumann-A]

• main goal: compile xserver everywhere. (extracted from [VTK-m/VTK/ParaView] Add new port (might work now) #9202)

will close the following issues
closes #6705

• depends [tool-meson] Rev vcpkg's meson build #15200
• depends [vcpkg_build_make] remove libtool artifacts #15622
• depends [vcpkg_apply_patches] don't change line endings on patching. #15578

[JackBoosY]

/azp run

[azure-pipelines]

Pull request contains merge conflicts.

[MVoz]

-- Installing x64-windows-rel
CMake Error at ports/xorg-macros/portfile.cmake:38 (file):
file RENAME failed to rename

E:/tools/vcpkg/packages/xorg-macros_x64-windows/share/aclocal/

to

E:/tools/vcpkg/packages/xorg-macros_x64-windows/share/xorg/aclocal

because: File exists

Call Stack (most recent call first):
scripts/ports.cmake:90 (include)

set(ENV{ACLOCAL} "aclocal -I "${CURRENT_INSTALLED_DIR}/share/xorg/aclocal/"")

vcpkg_configure_make(
SOURCE_PATH ${SOURCE_PATH}
AUTOCONFIG
#SKIP_CONFIGURE
#NO_DEBUG
#AUTO_HOST
#AUTO_DST
#PRERUN_SHELL "export ACLOCAL="aclocal -I ${CURRENT_INSTALLED_DIR}/share/xorg-macros/aclocal/""

original

packages\xorg-macros_x64-windows\share\xorg-macros\aclocal

why rename it? and then fix it in each port?

[JackBoosY]

/azp run

[JackBoosY]

Oh, sorry! I click the ready for review buttom...
If this PR is ready for review, please ping me.

[JackBoosY]

Pinging @Neumann-A for response. Is work still being done for this PR?

[Neumann-A]

@JackBoosY: This depends on #10402

[JackBoosY]

This PR has been inactive for a long time, please reopen it if there is any progress.

[Neumann-A]

@JackBoosY This PR just requires a word on how to deal with it on linux systems where x libs are normally provided by the system

[JackBoosY]

Should I reopen this? Should I give you some advice? But first you need to provide the current situation.

[Neumann-A]

@JackBoosY

Should I reopen this? Should I give you some advice? But first you need to provide the current situation.

So the problem is as follows:

• On Linux X is typically provided by the system. Should the port in vcpkg be empty in this case or should we switch it to dynamic linkage in this case? Or should there be a way to deactivate X for the user by setting some variable?
• A lot of ports depend on X but don't declare that dependency. I will probably not change any other ports to declare that dependency correctly considering the waste amount of ports. This needs to be done by other maintainers on port update.
• There is probably more to discuss but these are the biggest points which need to be solved first.

[JackBoosY]

On Linux X is typically provided by the system. Should the port in vcpkg be empty in this case or should we switch it to dynamic linkage in this case? Or should there be a way to deactivate X for the user by setting some variable?

All libraries provided only by the system should be set to empty ports, and search and use functions should be provided in them. Such as CUDA.

A lot of ports depend on X but don't declare that dependency. I will probably not change any other ports to declare that dependency correctly considering the waste amount of ports. This needs to be done by other maintainers on port update.

Yes, for those ports that use X libraries, they should explicitly state that they depend on X libraries, and these modifications can be done during the update. You can also temporarily disable these features that depends on X libraries.