Allow files in debug/share

[asfernandes]

There are dynamic libraries that need to locate files based on its path.

For example, lib/fbclient.so will locate the file in <path of itself>/../share/firebird/firebird.msg.

The problem is that debug/lib is in a different hierarchy level in relation to share than lib.

It does not feel right to recompile debug and release with different logic to locate others files, as debug files may land in a standard tree later (i.e., vcpkg_installed/triplet/debug/lib/* may go to install-prefix/lib.

So I propsoe the this warning is removed and files are allowed in debug/share.

warning: /debug/share should not exist. Please reorganize any important files, then use
file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/share")
error: Found 1 post-build check problem(s). To submit these ports to curated catalogs, please first correct the portfile: 

[autoantwort]

Could you workaround by using a symlink from debug/share to share?

[asfernandes]

Maybe in the client, but when I'm going to add the embedded version of Firebird database, i.e., the engine running as a library, then symlinks is problematic.

But are you suggesting to create symlink outside of vcpkg? Because I don't see a sense in vcpkg allowing a symlink but not a file.

Anyway, it looks hack for me and symlinks in Windows is not always available.

[asfernandes]

BTW, this is not a question (as labeled) for me. It's a feature request.

[Osyotr]

debug files may land in a standard tree later (i.e., vcpkg_installed/triplet/debug/lib/* may go to install-prefix/lib.)

...or it may land in an arbitrary tree. You really need to make it configurable (https://github.com/microsoft/vcpkg/discussions/35720#discussioncomment-7870278)

[asfernandes]

debug files may land in a standard tree later (i.e., vcpkg_installed/triplet/debug/lib/* may go to install-prefix/lib.)

...or it may land in an arbitrary tree. You really need to make it configurable (#35720 (comment))

That would be if vpkg is an inherent inflexible and unmaitained tool that people should always fight with it.

[github-actions[bot]]

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

[asfernandes]

I just hit this problem in https://github.com/microsoft/vcpkg/pull/36176 I'm still thinking is a completely nonsense thing.

[dg0yt]

It is debatable if it makes sense to a have a nearly identical copy of share in debug/share. And there are indications that deployment to the app location is more relevant than location in the installed tree.

[dg0yt]

BTW the problems of https://github.com/microsoft/vcpkg/pull/36176 should be discussed there. Not a typical case ATM.

[asfernandes]

As labelled as question, it's not going to be discussed by vcpkg core team.

[github-actions[bot]]

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.