Repository navigation
Figure out the packaging story for Beman #178
Description
Activity
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.
@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.
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,taskandnet. 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 thenetlibrary 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.
I think you should look at
utf_viewandtransform_viewinstead (utf_viewdepends ontransform_view); those libraries are more in sync withexemplarthanexecution,task, andnet, so it'll be easier to back propagate changes based onutf_view/transform_viewintoexemplarand from there to most other Beman libraries.@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.
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:
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.
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.
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.
@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.
Reacted by Claus Klein- 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: ***@***.***>
@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_viewandtransform_viewas suggested by @ednolan.The conan guy are extremely helpful and knowledgable, they could also guide us in the right directions.
I have created the first package for
transform_view. I have created this PR to have some initial discussions before submitting a PR in the official conan-center-index.To note: I chooesed
beman-transform_viewand notbeman.transform_viewbecause I am not sure about the policies for package names. I need to research this. But I am surprised of the choice to use '.' for cmake, I was thinking that was not an option.Please note that I am referring to a forked version of
transform_viewto my GitHub and created a release so it can be downloaded from conan. The hash used for the release is coming from this lockfile.json.How to use it:
- install conan and make sure it's in the path.
- Set up the profile like in https://docs.conan.io/2/tutorial/consuming_packages/build_simple_cmake_project.html.
- create the following
conanfile.txt:[requires] beman-transform_view/0.1.0 [generators] CMakeDeps CMakeToolchain [layout] cmake_layout - CMakeFiles.txt:
cmake_minimum_required(VERSION 4.0) project(transform_view CXX) find_package(beman.transform_view CONFIG REQUIRED) add_executable(transform_view src/main.cpp) target_link_libraries(transform_view PRIVATE beman::transform_view)
- invoke conan:
conan install . -s compiler.cppstd=23 - invoke cmake:
cmake --preset conan-release
Before switching to
utf_viewlet's see how the discussion evolves :)I'm looking forward for feedbacks.
11 remaining items
I want to be able to build and install a library with CMake only, like Boost.
I'm struggling to understand your point, and I'm trying to make it constructive, but I feel you have gaps in your knowledge of package managers. I'm failing to understand what this has to do how on how you build boost and how you use it.
Please make the conversation constructive and let's focus on the package manager aspect instead.
What, in the small prototype I'm proposing, is failing to meet your expectations from the point of view of a user using conan or vcpkg? That would be more appreciated feedback to me.
Did you try to create and consume those packages with conan?
Did you try to create and consume those packages with conan?
I Worked with i.e.:
- https://github.com/aminya/cpp_vcpkg_project
- https://github.com/cpp-best-practices/cmake_conan_boilerplate_template
- https://github.com/ClausKlein/cmake-init-conan
- https://github.com/ClausKlein/cmake-init-vcpkg-example
and and today, if this fails to build on my OSX, I simply disable the package manager and than I can build with
CMakeonly.
And too, if it fails withCMake, I can simple help me myself.Boost was only an example for a comparable project with a release and package strategy.
Claus, I'm also struggling to understand the relevance of your points here. My goal is for Beman libraries to support being consumed with vcpkg and conan, but to have that change be purely additive; adding support for these package managers is not expected to have any effect on your ability to consume the library with plain CMake. This is also the case with Boost's conan support, as evidenced by the fact that you're able to "simply disable the package manager and then I can build with CMake only." That will also be possible to do with Beman libraries after adding we add support for conan and vcpkg, so I don't understand what the issue is. If the complaint is about prioritization ("NO centralised approved build concept yet"), yes, there are many aspects of the Beman project that are works in progress, but I don't see why that should block the package manager work in any way.
Next step would be to understand how to make grouping happening.
From the previous message from @JeffGarland
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.
I could look into that as well to see if the current approach is suitable or not.
But befire that we need to establish some conventions:
- name of the package: I opted for beman-<project_name>.
- Versioning strategy. I would prefer semantic versioning, which I understand is also the current strategy.
- Tagging and Relasing. Most of the conan recipe requires to download the source code somewhere (as a tarball or zip). Usually this place for projects hosted in GitHub is the Release page. I would suggest to create tags for every version and than create releases based on this tags, like I did in the my fork of
transform_viewandutf_view.
Other aspects are less relevant like "NO centralised approved build concept yet" IMHO even if is a nice to have.
Next step would be to understand how to make grouping happening.
Boost uses a superproject/subproject approach for this. That might work, I'm not sure. For me the properties of a combined repo are as follows using 'ranges' as the example:
- ranges/includes/beman contains all the subdirectories for the aggregated libs.
- same for tests and examples
- ranges/CMakeLists.text is able to build and test all subrepos
- RANGES_BUILD_TEST type flags would control the subprojects
- subproject cmake files would remain unchanged
- A release of ranges would pull the latest release of the subprojects (idk about combined release notes)
- the resulting module will have all the modules from the subrepos
- we may consider having group-repo/examplar to instatutionalize this
I would suggest we create a complete seperate issue for that conversation/effort -- and maybe a discourse conversation first.
name of the package: I opted for beman-<project_name>.
sounds good.
Versioning strategy. I would prefer semantic versioning, which I understand is also the current strategy.
Tagging and Relasing. ...Yes, that should all be covered here hopefully. If you find problems of course please submit issues.
Reacted by Elvis DukajChiming in from Conan Center.
Last year I did work on a proof of concept for recipes for Beman
https://github.com/jcar87/beman.conanAs far as we are aware from Conan Center, we want to make sure the package names, version conventions, relations between them are all consistent with other package managers as well where Beman made available.
If there's a chance that it may make more sense for the recipes (the conanfile.py) to be hosted inside the
bemaprojectGitHub organisation, we could probably consider how to sync them up and have them available in the Conan Center remote.Reacted by Eddie Nolan@jcar87 Thanks for pointing this out -- I expect we will be working on this topic at c++now in aspen in a couple of weeks.
make sure the package names, version conventions, relations between them are all consistent with other package managers as well where Beman made available
This makes sense and I think we're well positioned to do that as the beman.standard sets conventions for these things. I believe at the moment our philosophy is we're only going to export production ready libraries to package managers. Also I see in your repo 'infra' and 'exemplar'. I'm not sure these should be part of conan packages as exemplar is a template and infra contains CI infrastructure that gets pulled into each repo directly so that they can stand alone. Thus a version of optional will already contain the needed infra parts under it's 'infra' directory.
recipes (the conanfile.py) to be hosted inside the bemaproject GitHub organisation, we could probably consider how to sync them up and have them available in the Conan Center remote
Wouldn't these live in the repo for the library itself?
Post-bemanproject/exemplar#366, I think I can declare this issue closed. Conan support would be nice for the future, but currently we have a setup where the vast majority of Beman libraries are packaged with vcpkg.
also I see in your repo 'infra' and 'exemplar'. I'm not sure these should be part of conan packages as exemplar is a template and infra contains CI infrastructure that gets pulled into each repo directly so that they can stand alone. Thus a version of optional will already contain the needed infra parts under it's 'infra' directory.
Thanks @JeffGarland - I worked on this example around September 2025 just as an illustration with @bretbrownjr - I think I added exemplar simply because it had tagged releases and was easy just as ademo.
infrais indeed not needed, it turns out that the specific commit I had used forexemplarwas not correctly setting up the CMake find path to resolvefind_package(beman-install-library REQUIRED).This makes sense and I think we're well positioned to do that as the beman.standard sets conventions for these things. I believe at the moment our philosophy is we're only going to export production ready libraries to package managers.
Looking at https://bemanproject.org/docs/beman_standard I think it's clear that libraries are called with a
beman.prefix - but then the repositories havebeman_, and the vcpkg names havebeman-. So I was hoping for some clarity with respect to the "package" name both in CMake and elsewhere; e.g. if it was to be installed with Conda, vcpkg, homebrew, spack, what "name" do users reference at the tool level?For Conan we prefer names that align with what is used elsewhere - we very much want users to be able to "swap" between different package management such that their build scripts remain Conan agnostic - so we want to avoid "Conan" specific things where at all possible, even if it is something as seemingly trivial as a package name.
Post-bemanproject/exemplar#366, I think I can declare this issue closed. Conan support would be nice for the future, but currently we have a setup where the vast majority of Beman libraries are packaged with vcpkg.
This is a bit surprising to me because reading the messages in this issue, Im not sure there are definitive answers to things such as naming, versioning or release conventions (other than "having releases"), or the pre-existing discussion in https://discourse.bemanproject.org/t/make-beman-packageable/331. Or, given that it seems that each project will be released/packaged independently, what happens if there are eventually dependencies between them - do we risk diamond dependency issues? Especially when we are at a stage when all libraries have an "API may change in the future" warning.
For example, https://github.com/bemanproject/execution still doesn't have releases. And "optional", which is marked as production ready, is missing in the registry.
Most comments in this issue mention Conan (which is the reason I ended up in this thread to being with), as there are interest from both users and maintainers - so I'm surprised (if not disappointed) that bemanproject/exemplar#366 got merged without comments from any of the reviewers, as it does seem to send a clear message in a different direction:
The best way to install the project's dependencies is to use the vcpkg workflow.
To do so, make sure vcpkg is installed and
VCPKG_ROOTis defined in your environment,We remain available to collaborate or provide guidance if you'd like to replicate a similar structure for Conan recipes. Otherwise, @steve-downey I'm very happy to advance a recipe for optional in Conan Center to make it more widely available to users, and @dukaje please let us know which libraries you'd first like to see in Conan Center.
That @jcar87 . Quick note, more later after I finish my talk for today :)
We've been discussing this at c++now this week and as Eddie said we have created initial answers for vcpkg. That solution involves a local repo that gets updated by CI when a release is made.
In researching conan capabilities it looks like there's an experimental feature to do something similar in conan.
So, I'm going to reopen this issue since the conan part of the story isn't complete. It might be the case that we still want to close this and have an issue focused on conan, but we can debate that later.
One more thought @jcar87
So I was hoping for some clarity with respect to the "package" name both in CMake and elsewhere; e.g. if it was to be installed with Conda, vcpkg, homebrew, spack, what "name" do users reference at the tool level?
This is a good point. I think for beman boost is a mostly good analogy as we have a collection of libraries. In conan Boost uses naming like boost::date_time, boost::mp11, etc. It would be natural for us to have beman::scope, beman::monadics, etc. To clarify for the non conan users following this discussion this is basically the name added to cmake library dependencies.
Boost has one other novel element that I think doesn't apply for beman -- that is the name boost::boost. That has the impact of setting up the includes for any boost header only library. It should likely be discouraged practice, but it is handy in the case of boost where the release is normally together.
@jcar87 do you have any pointers to how boost is handling their setup?
We've been discussing this at c++now this week and as Eddie said we have created initial answers for vcpkg. That solution involves a local repo that gets updated by CI when a release is made.
In researching conan capabilities it looks like there's an experimental feature to do something similar in conan.
Thanks @JeffGarland!
Yes, this would be entirely possible. I think there's 3 options:
- The Conan recipes could live in each repository and potentially validated by CI directly as the code evolves
- There could be a dedicated repository, akin to
vcpkg-registry, that has all the recipes - in most cases, updating the recipes to "reflect" a new version is a few lines that need to change. So this could tie in nicely with a CI-driven release workflow - Or we could just have the recipes in Conan Center Index - typically users just contribute this to the
conan-center-indexrepository on GitHub, and once it goes through human+CI validation, they are made available in the Conan Center remote.
In all cases the biggest difference is when the recipes are validated (with each commit, with each release, or on-demand), and how the users/consumers "get" them. But otherwise the actual recipes are likely to be the very same with very few lines of implementation. Note that for Conan (and to an extent, others like vpckg, spack, etc), it is preferable to have actual release numbers pointing to tags.
This is a good point. I think for beman boost is a mostly good analogy as we have a collection of libraries. In conan Boost uses naming like boost::date_time, boost::mp11, etc. It would be natural for us to have beman::scope, beman::monadics, etc. To clarify for the non conan users following this discussion this is basically the name added to cmake library dependencies.
There's probably different levels of naming - they don't all necessarily need to be aligned with each other but they probably need to be consistent within each level:
- The name of the "package" as seen by a package management tool (e.g. apt-get, vcpkg port, conan recipe, etc) - This is the name that a user types either in the command line of their tool, or a file that specifies the dependencies
- The name of "CMake" package (or CPS) - this is what they type in
find_package(xxx)in CMake - The name of the of the specific CMake or CPS targets for the libraries - e.g
beman::foobar. From what I can see, bothbeeman::foobarandbeeman.foobarare currently used. These would be used intarget_link_librarieson the consumer projects. - The C++ namespaces
- and where relevant, the C++ module name (
import xxx)
It is the first one (the name of the package/recipe) that I was waiting guidance on, for Conan, as we try to keep the names aligned with other repositories. Not always possible, and if there symbols in the name (
.,-,_, etc), not all tools allow the same symbols.If the Beman header-only libraries are not designed to be a "catch all" thing that all live in the same root - perhaps no need to worry about having something like
Boost::boostorBoost::headers.more later after I finish my talk for today :)
Hope the talk went well!Talk not done yet, but quick note.
There could be a dedicated repository, akin to vcpkg-registry, that has all the recipes - in most cases, updating the recipes to "reflect" a new version is a few lines that need to change. So this could tie in nicely with a CI-driven release workflow
I think this is the way we're leaning. Basically with the latest change @ednolan put facilities to take a template from the repo and update the vcpkg repo. He'll have to chime in on the details there.
https://github.com/bemanproject/monadics/blob/main/vcpkg.json
Is there a project that's doing this we could look at?
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.