[boost-*] Header-only support

[Zitrax]

Is your feature request related to a problem? Please describe.

We are using boost on platforms without thread support and the current ports do not build, for example boost-container and some others. However we can use them in header only mode, but I found no way of telling the vcpkg boost ports to either skip building or disabling thread support.

So at the moment as a workaround I have added overlays that simply comment out the build part, such that we can still pick up the headers like so:

#include(${CURRENT_HOST_INSTALLED_DIR}/share/boost-build/boost-modular-build.cmake)
#boost_modular_build(SOURCE_PATH ${SOURCE_PATH})

include(${CURRENT_INSTALLED_DIR}/share/boost-vcpkg-helpers/boost-modular-headers.cmake)
boost_modular_headers(SOURCE_PATH ${SOURCE_PATH})

keeping the headers part only.

Proposed solution

Since all (?) boost ports seem to follow the same pattern with separation of building and headers could this be made into proper vcpkg feature or similar to avoid the local overlays?

Or is there another way to achieve a solution to my problem that I have missed?

Describe alternatives you've considered

No response

Additional context

No response

[Neumann-A]

Mostly header-only, library compilation is required for few features.

I don't see why vcpkg should support something upstream does not actively support.

[Zitrax]

Mostly header-only, library compilation is required for few features.

I don't see why vcpkg should support something upstream does not actively support.

On the other hand it feels like it should be possible to use header only mode for libraries that support it without being forced to build it.

For example it looks like Conan support this with an option boost:header_only=True, doesn't sound unreasonable to me that vcpkg could offer something similar.

[Kojoley]

Mostly header-only, library compilation is required for few features.

I don't see why vcpkg should support something upstream does not actively support.

There are some libraries that explicitly support both header-only and compiled library. (I think Beast, Regex)

Threads support can be disabled via threading=single, I don't know how well it is tested though.

[Zitrax]

Threads support can be disabled via threading=single, I don't know how well it is tested though.

But is there a way to pass that to the boost vcpkg ports without adding your own overlay?

[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.

[Zitrax]

Ping.

[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.

[Zitrax]

Keep it open.

[jasongodev]

Hi everyone, one scenario where header-only install will be beneficial is for building apps in containerized environments such as Flatpaks. I came across a Flatpak packaged app called MEGAsync which is using vcpkg to manage dependencies. I was able to have a workaround on how to prevent vcpkg to download sources in a flatpak sandbox where downloading via curl is not allowed.

Okay, well and done, but one concern is that I can not prevent vcpkg from building dynamic libraries that are already provided by the system. Yes, you can use overlay ports to tell vcpkg to use the system libraries BUT in flatpak's case the header files are not included in the system environment because flatpak is using the smallest possible environment build and no dev files are included in the runtime.

So it will be nice if vcpkg has built-in header-only installs, or something like export headers mode, or a VCPKG_BUILD_TYPE=dev in addition to release and debug types.

For now what I did is to allow all dependencies to be built then use a cleanup routine to delete the libraries from the final build. Works well but the wasted compile time is really painful to watch.