Mostly GitHub workflow and build system changes

[jeremy-murphy]

And some fixes to the documentation, and one fix to the code.

Also updated the maintainer to myself, which I should have done a few years ago when I took over Boost.Graph, whoops.

[jeremy-murphy]

@jzmaddock , are you available to review?

[jzmaddock]

The changes look fine to me. Any idea what's started causing all the segfaults in the tests?

[jzmaddock]

BTW we could really use an MSVC CI runner too.

[jeremy-murphy]

The changes look fine to me. Any idea what's started causing all the segfaults in the tests?

No idea! I'll have to investigate.

[jeremy-murphy]

Very curious that the macos (clang) build passes.

[jeremy-murphy]

@aminiussi maybe you can help here: do you know why these mpich builds fail?

[aminiussi]

I test boost.mpi with HPE/Cray MPI which is mpich based so nothing trivial comes to mind.

I only test with cmake and I think there are no cmake based tests for graph parallel, so I'll have to make a b2/gcc13/mpich build on my ubuntu laptop to sees if I can reproduce the issue.

[aminiussi]

I would replace:

mpi_process_group pg;

with

boost::mpi::communicator world{};
BOOST_TEST(world.size() > 1); // not supposed to work on one proc
mpi_process_group pg{world};

Then, I suspect the test will fail the BOOST_TEST(world.size() > 1) check as the communicator size is 1 (and that is the real problem).

Since the mpi_process_group class allocate one incomming and outgoing communication structures in containers of size comm.size(), sending a message to proc 1 will retrieve a non existing outgoing structure (in mpi_process_group.ipp:173).

I suspect the problem is in the project_config.jam generated file that does not actually select the mpich implementation, which ends up launching 2 singleton instead of two process MPI jobs.