Vcpkg: [question/suggestion] Package Layout

[podsvirov]

Why do you move executable files to a subfolder for tools?
Where about this is written in the documentation?

Based on my experience, I can say that many package managers do not do this. Also, nobody canceled the FHS, which is very popular among open source projects.

What about adding a policy (option) to control this behavior?

It would also be nice to split the package into components (for example: executable files (debugging), runtime libraries (debugging), link libraries (debugging), header files, debugging symbols). This will help improve the export command.

[podsvirov]

@ras0219-msft , any feedback, please?

[ras0219-msft]

Vcpkg is first and foremost a C/C++ _libraries_ developer tool, not a user-facing application package manager. We want to give you a consistent set of libraries to build your application, which requires building them from source. These libraries, for the _target_ system, are what goes into bin\ and lib\.

Executables, on the other hand, must be compiled for the host system. They often don't need to be built using the exact same library versions as your final application. Further, the applocal behavior of the Windows loader means that an executable really isn't "complete" by itself -- you must consider the entire folder it lives in as the application. All these aspects come together to determine the primary way applications on windows are deployed: using Program Files\<foo>\app.exe.

Due to the target vs. host issue above, it's unavoidable that in some situations the executables _must_ be relocated (bin\zlib.dll is ARM64, but mytool.exe depends on a zlib.dll that is compiled for x64). In order to ensure consistency, we should always relocate them. The fact that this isn't the default has the side-benefit that every executable is explicitly considered whether to be appropriate for vcpkg.

It would also be nice to split the package into components (for example: executable files (debugging), runtime libraries (debugging), link libraries (debugging), header files, debugging symbols). This will help improve the export command.

While splitting these may be possible, I think the added complexity outweighs the benefits for the core experience. In the specific case of the IFW installer (since I assume that's what you're talking about here), I think it might be reasonable for a specific exporter to split the packages based on layout:

• tools\ fractures into "executable files"
• include\ fractures into "header files"
• bin\*.dll are the "runtime libraries"
• lib\*.lib and lib\manual-link\*.lib are the "link libraries"
• bin\*.pdb and lib\*.pdb are the "debugging symbols"

However, I think the core experience (as an _application development tool_) is better served by treating zlib and sdl2 as simple, atomic units that can be developed against instead of managing zlib-headers+zlib-symbols+zlib-libs-debug+zlib-libs-release+....

[angelmixu]

@ras0219-msft hi! just wondering...

actually we have this structure inside the installed subdirectory of a triplet:

• bin
• debug
• 
  
  • bin
  
  
• 
  
  • lib
  
  
• include
• lib
• share
• tools

I'm used to configure VS projects for different archs and configurations as paths like this one:
path_to_libraries_repository\$(Platform)\$(Configuration)\include
path_to_libraries_repository\$(Platform)\$(Configuration)\lib

Platform being for example Win32, x64. And Configuration Release, Debug.
So I only have to set it once for all configurations and platforms.

In the actual directory layout I don't have any way to simplify it with my usual layout, I was wondering if I could configure vcpkg for using the following layout:

• debug
• 
  
  • bin
  
  
• 
  
  • lib
  
  
• include
• release
• 
  
  • bin
  
  
• 
  
  • lib
  
  
• share
• tools

As it seems easier for VS configurations. Or maybe, is there a way to use on VS a conditional macro for being 'debug' when in debug and being '' (empty) when in release. But I have been searching for it and haven't found anything :(

EDIT: also with some debug libraries there's a 'd' suffix for debug ones, how should I configure it in order to make it generic across all platforms and configurations?

[ras0219-msft]

If you're using VS, we highly recommend using one of our MSBuild integration methods[1], which will handle this for you.

The reason for not placing release binaries into a subdirectory is because:

1. The default for most buildsystems is to install into $prefix\include\ $prefix\bin\ and $prefix\lib\
2. Many buildsystems also make it very easy to read the above layout.

Therefore, while we certainly can't satisfy _every_ buildsystem's needs, laying out release binaries like we have makes it as easy as possible for those users.

From MSBuild, you could create a conditional macro via something like:

<MaybeDebug Condition="'$(Configuration)'=='Debug'">debug\</MaybeDebug>
<MaybeDebug Condition="'$(Configuration)'!='Debug'"></MaybeDebug>

then use it as path\$(MaybeDebug)lib.

[1] https://github.com/Microsoft/vcpkg/blob/41a0eee5d10c31c7c3a157454d251dda10bd20fe/docs/users/integration.md

[angelmixu]

Oh thanks!!!
I've built a Properties Sheet file for all projects and works perfect!!! :D