Figure out the packaging story for Beman

[ednolan]

We need to develop a well-thought-out strategy for packaging Beman, both on the level of individual libraries and as a group of packages à la Boost.

[dukaje]

I also feel this. This project should be easy to be consumed by engineers to be adopted! Packaging should be a priority for the library. I can help in creating conan packages.

[JeffGarland]

@dukaje welcome! Can you please work with @steve-downey on getting optional ready for conan? That's our primary production ready library and it should be in conan as soon as possible.

Noting that this thread is dormant for a long time it's something that I plan to raise as a topic at C++Now. We've advanced dramatically on infrastructure, but not here. The grouping issue is another thing, but matters much less if everything is in conan and vcpkg. Right now on grouping I'm thinking on obvious grouping is beman.ranges -- which gathers up the 1/2 dozen+ range related repos into a coherent package. But that's a non-tirival project by itself even though the basic repo design is there to support.

[dukaje]

I am not very familiar with the structure of the code but I did past job in porting existing project to conan.

My idea would be to move the whole packaging in the conan-center-index so that would be community maintained. I was thinking to start from 3 projects like executor, task and net. I'd like to create 3 PRs on the conan-center-index and we can move the discussion there.
One thing that is actually challenging in the current situation is that there is no versioning of the library. Browsing the code I see that the version of this library is pretty loose while packages requires stricter rules about that. For instance in the net library I can see:

FetchContent_Declare(
    execution
    # FETCHCONTENT_SOURCE_DIR_EXECUTION ${CMAKE_SOURCE_DIR}/../execution
    GIT_REPOSITORY https://github.com/bemanproject/execution
    GIT_TAG 66295d5
    SYSTEM
    FIND_PACKAGE_ARGS
        0.2.0
        EXACT
        NAMES
        beman.execution
        COMPONENTS
        execution_headers
)
FetchContent_MakeAvailable(execution)

It is not clear to me how the commit 66295d5 is related to the version 0.2.0.

It would be way easier to create some tags instead, or even better releases. This way I could have a 1:1 relationship with the branch and the version.

I'd like to hear any feedback, and don't hesitate to correct any gap in my knowledge since I am not very familiar with the structure of this project.

[ednolan]

I think you should look at utf_view and transform_view instead (utf_view depends on transform_view); those libraries are more in sync with exemplar than execution, task, and net, so it'll be easier to back propagate changes based on utf_view/transform_view into exemplar and from there to most other Beman libraries.

[elvisdukaj]

@ednolan it sounds like a plan. I can look into the suggested library, prepare a local PR we can discuss. My main concern is the versioning of the library. And download the repo, given a specific version. For the case of execution no tag were used.

Is there some guideline I can look into?

P.S.: I'm sorry I'm replying with another account, but this is my private account and I'm not representing my company here.

[ednolan]

Although unfortunately we haven't done a good job keeping them up to date, beman.exemplar has some releases you can look at as precedent:

https://github.com/bemanproject/exemplar/releases

[elvisdukaj]

We need to develop a well-thought-out strategy for packaging Beman, both on the level of individual libraries and as a group of packages à la Boost.

To have such a system we will need a single version for all the libraries, but I also see many downsides of the current Boost packaging. Many projects I know put down boost because it's too massive. If you need only asio you have to download all the other dependencies.
Is this the desired direction?

Also, a packaging á la Boost fits best in a mono repo, where all the source code is in a single place, while the beman is not.

These are important decisions that can be hard to change later.

I suggest working the other way around. Instead of creating packages, let's try to see how we would like to use them from the client's perspective. Maybe it will be easier to make choices with a small prototype to work with.

[ednolan]

I think in general the direction for the Beman project has been along the lines of thinking about the libraries as individual libraries rather than a Boost-style suite of them. So the versioning would be decided on a per-library basis instead of marking every library as version 1.91 like Boost does.

I'm definitely in favor of small prototypes. Feel free to fork and/or branch any of these libraries as needed.

[ednolan]

packaging Beman, both on the level of individual libraries and as a group of packages à la Boost

I realize now that Boost-style packaging was part of my original set of requirements for this issue. Maybe we should drop that. Or maybe just scale that down to something along the lines of, "there is a way for users of package managers to spell 'give me every beman library' or 'give me the beman views libraries'," without needing anything more sophisticated than that.

[JeffGarland]

@dukaje and @ednolan I think the Boost style packaging should be dropped for the moment -- we realized since this issue was written that single library distrubution is perferred in most instances. I do think we will eventually have bundles of libraries as well. For example we might want Beman.cpp29 as a bundle or Beman.ranges (includes 26 and 29 content). I'm hoping we'll design an architecture for that in Aspen this year.

[steve-downey]

I would love to get optional into Conan. That might even be enough for me to figure out how to use it myself. Hopefully the structure is pretty simple, and the CMake is boring enough that packaging can reuse the existing build infrastructure. It should have all the customary targets and respect the toolchain the package build wants it to use. The Makefile is purely workflow, the build is all really Cmake. As a matter of policy, as well as for my own sanity using these kinds of libraries at work, the build will not add flags on its own, or change anything, preferring to fail instead. That might occasionally surprise, but it's important when building packages independently to link together. Any questions please tag me or email me directly, just in case anything gets buried in my inbox.

…

On Thu, Mar 12, 2026, 05:31 Elvis Dukaj ***@***.***> wrote: *dukaje* left a comment (bemanproject/beman#178) <#178 (comment)> I am not very familiar with the structure of the code but I did past job in porting existing project to conan. My idea would be to move the whole packaging in the conan-center-index so that would be community maintained. I was thinking to start from 3 projects like executor, task and net. I'd like to create 3 PRs on the conan-center-index and we can move the discussion there. One thing that is actually challenging in the current situation is that there is no versioning of the library. Browsing the code I see that the version of this library is pretty loose while packages requires stricter rules about that. For instance in the net library I can see: FetchContent_Declare( execution # FETCHCONTENT_SOURCE_DIR_EXECUTION ${CMAKE_SOURCE_DIR}/../execution GIT_REPOSITORY https://github.com/bemanproject/execution GIT_TAG 66295d5 SYSTEM FIND_PACKAGE_ARGS 0.2.0 EXACT NAMES beman.execution COMPONENTS execution_headers ) FetchContent_MakeAvailable(execution) It is not clear to me how the commit 66295d5 <bemanproject/execution@66295d5> is related to the version 0.2.0. It would be way easier to create some tags instead, or even better releases. This way I could have a 1:1 relationship with the branch and the version. I'd like to hear any feedback, and don't hesitate to correct any gap in my knowledge since I am not very familiar with the structure of this project. — Reply to this email directly, view it on GitHub <#178 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVNZ5V32FZ4DMQLHXPUR2D4QJ7YXAVCNFSM6AAAAACWOCCSX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANBVGI2DOMZUGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[elvisdukaj]

@steve-downey I will port some of the packages on the conan-center-index and have a meangful discussion there. But if we want to have any kind of meaningful discussion we should be clear in versioning the libraries and tag/release them.

I will pickup utf_view and transform_view as suggested by @ednolan.

The conan guy are extremely helpful and knowledgable, they could also guide us in the right directions.