Support standalone builds and clean up test/CMakeLists.txt

[chandryan]

Applied changes:

• Introduced a check whether MSM is built as part of the super-project or standalone in the root CMakeLists.txt
• Removed/fixed the code related to building the tests standalone in the test CMakeLists.txt
• Added the missing dependency to the CMake tests target

Resolves #111

[Flamefire]

Should work, just a missed indent.

What exactly is BOOST_MSM_NONSTANDALONE_TEST used for? It doesn't seem to be required for the B2 based build so why for the CMake build?

The intention was the former: Calling cmake from msm, though I just tried out building the tests as part of the super-project and it works well for me - I'll stick to that in the future.
[...]
Despite my need of running the tests standalone having vanished, I guess the option to build MSM standalone might be useful.

Doesn't hurt I guess, as the additional code is small.
But it might be better to just support the integrated/super-project build unless you are reasonably sure MSM doesn't (and will not) rely on any Boost features introduced after 1.66.

Also supporting 3 types of testing (CMake super-project, standalone, b2) might be a maintenance burden. But that's up to you of course.

Anyway this change looks sound and is certainly an improvement.

[chandryan]

What exactly is BOOST_MSM_NONSTANDALONE_TEST used for? It doesn't seem to be required for the B2 based build so why for the CMake build?

The test Jamfile creates an executable for each source file, in this case BOOST_TEST_MODULE is not defined and a main function is provided in each source file by defining BOOST_TEST_MODULE.
For CMake I have added a separate main.cpp and defined BOOST_MSM_NONSTANDALONE_TEST, since all tests run in one executable.

Also supporting 3 types of testing (CMake super-project, standalone, b2) might be a maintenance burden. But that's up to you of course.

Indeed, I would like to retain the CMake version due to better IDE integration in VS Code. I'll check on that.

[Flamefire]

What exactly is BOOST_MSM_NONSTANDALONE_TEST used for? It doesn't seem to be required for the B2 based build so why for the CMake build?

The test Jamfile creates an executable for each source file, in this case BOOST_TEST_MODULE is not defined and a main function is provided in each source file by defining BOOST_TEST_MODULE. For CMake I have added a separate main.cpp and defined BOOST_MSM_NONSTANDALONE_TEST, since all tests run in one executable.

I see, yes that makes sense. You could do the same in the Jamfile if you want, but I guess this separation gives a bit faster turnaround times on CI due to parallelisation.

BTW: For your file(GLOB ...) you can add CONFIGURE_DEPENDS if you require CMake 3.12+ in the main CML

Also supporting 3 types of testing (CMake super-project, standalone, b2) might be a maintenance burden. But that's up to you of course.

Indeed, I would like to retain the CMake version due to better IDE integration in VS Code. I'll check on that.

I wasn't suggesting dropping the CMake version just to use the regular super-project version that doesn't require a find for an installed Boost. But as mentioned, now the additional code is minimal and if this is just a "hidden feature" you don't need to care about it not working with any Boost version

[chandryan]

BTW: For your file(GLOB ...) you can add CONFIGURE_DEPENDS if you require CMake 3.12+ in the main CML

Ahh nice, thanks for the tip! I didn't know about this setting yet and usually sticked to listing the files manually.

Also supporting 3 types of testing (CMake super-project, standalone, b2) might be a maintenance burden. But that's up to you of course.

Indeed, I would like to retain the CMake version due to better IDE integration in VS Code. I'll check on that.

I wasn't suggesting dropping the CMake version just to use the regular super-project version that doesn't require a find for an installed Boost. But as mentioned, now the additional code is minimal and if this is just a "hidden feature" you don't need to care about it not working with any Boost version

I meant to say I would like to retain the CMake version(s) and eventually drop b2, if possible.

[Flamefire]

Ahh nice, thanks for the tip! I didn't know about this setting yet and usually sticked to listing the files manually.

Listing the files manually is actually preferred because the GLOB does not regenerate the build files when adding new files so manual work is required either way, even if just rerunning CMake. CONFIGURE_DEPENDS is a "good enough" alternative though.

I meant to say I would like to retain the CMake version(s) and eventually drop b2, if possible.

As b2 is still the main build system I wouldn't do so. You can generate your CMake tests automatically from the test Jamfile, although that results in the same individual executables as b2 creates. This ensures they stay consistent.
And b2 still has advantages like the multi-config testing. With Boost.CI it is easy to get a very wide coverage of compilers and standards with a small CI file. That is based on B2 too although they are CMake tests included but only for a single compiler (per OS)

[pdimov]

Now the CMake tests fail with

In file included from /home/runner/work/boost/boost/libs/msm/test/Back11OrthogonalDeferred3WithPuml.cpp:15:
/home/runner/work/boost/boost/libs/msm/include/boost/msm/front/puml/puml.hpp: In function ‘constexpr auto boost::msm::front::puml::detail::parse_guard_simple(Func)’:
/home/runner/work/boost/boost/libs/msm/include/boost/msm/front/puml/puml.hpp:507:25: error: lambda-expression in unevaluated context only available with ‘-std=c++20’ or ‘-std=gnu++20’
  507 |                         [=]() {return boost::msm::front::puml::detail::cleanup_token(guard_func().substr(0, last_or_pos)); })),
      |                         ^

https://github.com/boostorg/boost/actions/runs/18063746716/job/51403678027

[Flamefire]

if(CMAKE_CXX_STANDARD LESS 20) succeeds if CMAKE_CXX_STANDARD isn't set as seeming "CMAKE_CXX_STANDARD" < 20 (i.e. the string) doesn't hold

#116 should fix it.

[chandryan]

Now the CMake tests fail with

In file included from /home/runner/work/boost/boost/libs/msm/test/Back11OrthogonalDeferred3WithPuml.cpp:15:
/home/runner/work/boost/boost/libs/msm/include/boost/msm/front/puml/puml.hpp: In function ‘constexpr auto boost::msm::front::puml::detail::parse_guard_simple(Func)’:
/home/runner/work/boost/boost/libs/msm/include/boost/msm/front/puml/puml.hpp:507:25: error: lambda-expression in unevaluated context only available with ‘-std=c++20’ or ‘-std=gnu++20’
  507 |                         [=]() {return boost::msm::front::puml::detail::cleanup_token(guard_func().substr(0, last_or_pos)); })),
      |                         ^

https://github.com/boostorg/boost/actions/runs/18063746716/job/51403678027

Do you think it makes sense to add such a job to the MSM repo for better regression?

[Flamefire]

The CI is indeed missing CMake tests. Either add them or switch to the reusable Boost.CI workflow. See https://github.com/boostorg/boost-ci/blob/master/.github/workflows/ci.yml for big coverage of configs and automatic updates/fixes