Can vcpkg symlink $TRIPLET_INSTALL/debug/include -> $TRIPLET_INSTALL/include on Linux?

[jumpinjackie]

In the process of working on a fix for #6680 I found that the current vcpkg triplet install layout on Linux (and possibly OSX too) does not easily lend itself to internal vcpkg port consumption for ports whose build process involves a ./configure script invocation.

In the case of gdal and #6680 I tried to modify the portfile so that it runs ./configure with:

For release:

• --with-png=${CURRENT_INSTALLED_DIR}
• --with-proj=${CURRENT_INSTALLED_DIR}

For debug:

• --with-png=${CURRENT_INSTALLED_DIR}/debug
• --with-proj=${CURRENT_INSTALLED_DIR}/debug

Where ${CURRENT_INSTALLED_DIR} is the current triplet install directory variable provided by vcpkg.

This works fine in release mode, where ${CURRENT_INSTALLED_DIR}/include and ${CURRENT_INSTALLED_DIR}/lib will be present, but for debug the headers won't be detected by the configure script because the include directory doesn't exist in ${CURRENT_INSTALLED_DIR}/debug

If we're lucky, a configure script may offer the ability to specify --with-library-inc and --with-library-lib individually, but in the case of gdal (and possibly many other ports that use ./configure scripts), they mainly offer --with-library variant where the include and library paths are determined relative to the provided path.

So given this situation, would it be easy for vcpkg to create a symlink $TRIPLET_INSTALL/debug/include -> $TRIPLET_INSTALL/include when installing (and not already present) to allow ports like gdal to better take advantage of available vcpkg ports where available?

With this symlink in place, I can build gdal in debug and it can properly consume libpng and proj ports in debug.

This would beat the alternative of needing to provide configure script patches to allow passing include/lib paths separately.