Change exported install name to beman::execution26

[maikel]

According to https://github.com/bemanproject/beman/blob/main/docs/BEMAN_STANDARD.md the library should be exported as beman::execution26 but currently it is beman_execution26::beman_execution26

Take care: I did not check whether this breaks net29

[ClausKlein]

Do you know this cmake naming convention? https://discourse.cmake.org/t/fetchcontent-and-cache-variables-collisions/13236/2

[ClausKlein]

It is not clear to me why this additional headers are needed now?

The last CI runs worked without this headers???

We have to check the CI build rules!

[maikel]

We always need to install headers since this is a header only library. We simply forgot to add them to the file set when I implemented the awaitable helpers.

The things that I change here occured while I was using beman::execution26 as an installed library to implement a coroutine task. I couldn't use the library because headers were missing.

I was using it here
https://github.com/maikel/task

[maikel]

This is how I expect to consume beman.execution26

https://github.com/maikel/task/blob/main/CMakeLists.txt#L20-L26

[maikel]

Do you know this cmake naming convention? https://discourse.cmake.org/t/fetchcontent-and-cache-variables-collisions/13236/2

Indeed, I do not. I will have a look. I was just looking into the beman standard rules and was surprised to not have an beman::execution26 target that I can cmake-link against. AFAIU we provide a local beman::execution26 target but install beman_execution26::beman_execution26 so somthing is iffy here. I hope to fix that. But I changed more than that and if that violates other best-practises lets just do the very necessary changes

[maikel]

TODO: a good check whether we forgot to install all necessary headers in the FILE_SET could be to have a CI job that installs the library in the docker image and consumes it to build either the examples or the unit tests as an external provided library instead of in an in-tree build

[ClausKlein]

TODO: a good check whether we forgot to install all necessary headers in the FILE_SET could be to have a CI job that installs the library in the docker image and consumes it to build either the examples or the unit tests as an external provided library instead of in an in-tree build

it exists here https://github.com/bemanproject/execution26/blob/2d7e75e804a3bc57b9f9e5f251630d456576a7b9/tests/beman/execution26/CMakeLists.txt#L134

and it runs here https://github.com/bemanproject/execution26/actions/runs/12456083371/job/34769207665#step:4:922

@dietmarkuehl But for timing reason, only one test is compiled!

[maikel]

TODO: a good check whether we forgot to install all necessary headers in the FILE_SET could be to have a CI job that installs the library in the docker image and consumes it to build either the examples or the unit tests as an external provided library instead of in an in-tree build

it exists here

https://github.com/bemanproject/execution26/blob/2d7e75e804a3bc57b9f9e5f251630d456576a7b9/tests/beman/execution26/CMakeLists.txt#L134

and it runs here https://github.com/bemanproject/execution26/actions/runs/12456083371/job/34769207665#step:4:922

Hm, yes. Then that test doesn't detect the missing include files in the FILE_SET. Maybe it picks up the include directory of build dir instead of only considering the stage dir.

Edit: and we should make sure to build a test that uses all public headers, such as #include <beman/execution26/execution.hpp>

[dietmarkuehl]

Edit: and we should make sure to build a test that uses all public headers, such as #include <beman/execution26/execution.hpp>

Of course, that just kicks the can down the road: headers can also be missing from execution.hpp. There is actually a target (update) in the top-level Makefile which automatically adds all headers in include/beman/execution26 (and detail subdirectory) to the relevant CMakeLists.txt but not [yet?] to execution.hpp.

[dietmarkuehl]

TODO: a good check whether we forgot to install all necessary headers in the FILE_SET could be to have a CI job that installs the library in the docker image and consumes it to build either the examples or the unit tests as an external provided library instead of in an in-tree build

it exists here

https://github.com/bemanproject/execution26/blob/2d7e75e804a3bc57b9f9e5f251630d456576a7b9/tests/beman/execution26/CMakeLists.txt#L134

and it runs here https://github.com/bemanproject/execution26/actions/runs/12456083371/job/34769207665#step:4:922

@dietmarkuehl But for timing reason, only one test is compiled!

This one remaining test still takes more time than building the tests and running them together. I'm not objecting to testing that all files get properly installed. However, I run tests often during development and currently the first thing I tend to do is to disable this test.

[maikel]

TODO: a good check whether we forgot to install all necessary headers in the FILE_SET could be to have a CI job that installs the library in the docker image and consumes it to build either the examples or the unit tests as an external provided library instead of in an in-tree build

it exists here
https://github.com/bemanproject/execution26/blob/2d7e75e804a3bc57b9f9e5f251630d456576a7b9/tests/beman/execution26/CMakeLists.txt#L134

and it runs here https://github.com/bemanproject/execution26/actions/runs/12456083371/job/34769207665#step:4:922
@dietmarkuehl But for timing reason, only one test is compiled!

This one remaining test still takes more time than building the tests and running them together. I'm not objecting to testing that all files get properly installed. However, I run tests often during development and currently the first thing I tend to do is to disable this test.

But do you have to run an integration test in your local development? We could have a dedicated CI job that installs into a docker container and tries to compile an example using the freshly installed package.

[dietmarkuehl]

There are a few more headers also missing. I spotted

• intrusive_stack.hpp
• split.hpp

[dietmarkuehl]

This one remaining test still takes more time than building the tests and running them together. I'm not objecting to testing that all files get properly installed. However, I run tests often during development and currently the first thing I tend to do is to disable this test.

But do you have to run an integration test in your local development? We could have a dedicated CI job that installs into a docker container and tries to compile an example using the freshly installed package.

No, I don't. Effectively, I just build using make which uses the default target in the Makefile. That just depends on test which depends on build. test just run ctest with some options. If there is a setup to not run tests which should be part of the integration but are probably not part of building during development, that's fine.

I should really also add a target which does all the things getting ready to create a PR:

• update to add missing headers and (with an extension) check that all detail headers are used from at least one top-level header
• check to detect cyclic dependencies in headers (although I recently fixed some clang-tidy warnings which also detected cycles)
• clang-format (in theory format should do the trick but I don't have cmake-format installed)
• clang-tidy
• ce to build headers for Compiler Explorer (although that probably needs some work)
• possibly others

[dietmarkuehl]

The change looks good to me. I'll try it out and make sure that the list of headers is up to date. With that I'll plan to approve and land the changes. Moving the setup to be in line with other policies can be a separate PR.

[dietmarkuehl]

Aside from missing headers (and listing one header twice) the change also broke the header update script. With these also fixed, the change looks good.