Remove boost dependencies.

[fruffy]

We can likely clean up some dependencies on boost since we have upgraded to C++17. Two easy low-hanging fruits are boost::filesystem and boost::optional.

There is also (as suggested by GPT5.3):

• Easy win: Boost::thread
  • You’re using Boost shared mutex/locks in core paths (include/bm/bm_sim/.h, src/bm_sim/.cpp), e.g. boost::shared_mutex, boost::shared_lock, boost::unique_lock.
  • In C++17 this can be replaced with std::shared_mutex, std::shared_lock, std::unique_lock (<shared_mutex>, ).
  • That should let you remove Boost::thread from CMake (src/bm_sim/CMakeLists.txt:80) and related autotools checks (configure.ac:251).
• Medium effort: Boost hash helpers (boost::hash_combine)
  • Used in a few places (include/bm/bm_sim/P4Objects.h:442, src/bm_sim/debugger.cpp:174, include/bm/bm_sim/field_lists.h:125, etc.).
  • C++17 has no std::hash_combine, so you’d replace with a small local helper (common combine formula) and drop <boost/functional/hash.hpp> includes.

The last remaining piece is boost::program_options. I have great experience with CLI11: https://github.com/CLIUtils/CLI11

It's a standalone dependency and can be vendored, which makes it easier to work with.

@matthewtlam Could this be in scope for the GSoC modernization task you have in mind? Otherwise I kick this off myself.

[c8ef]

Hi @fruffy!

I'm one of the applicants for the GSoC project on BMv2. While my proposal outlines four potential approaches to codebase modernization, I hadn't considered modernizing the Boost dependencies - though I believe it fits well within the project's scope. Since I have availability now, I'm wondering whether we should wait until the project is officially announced (April 30) or if we can get started right away.

[fruffy]

Hi @fruffy!

I'm one of the applicants for the GSoC project on BMv2. While my proposal outlines four potential approaches to codebase modernization, I hadn't considered modernizing the Boost dependencies - though I believe it fits well within the project's scope. Since I have availability now, I'm wondering whether we should wait until the project is officially announced (April 30) or if we can get started right away.

We can wait until we officially announce the project. @matthewtlam @qobilidop any thoughts?

[qobilidop]

@fruffy @c8ef For this issue, I don't see the need to wait for GSoC project specifically.

In general, I'd prefer to minimize influence on this repo's normal development from GSoC. Ideally there should be zero-influence, but in practice, this year we are using the Bazel build setup task as a qualification task, so that task is blocked by the GSoC process. But other than that specific task, I'd say nothing should be blocked by the GSoC process.

[asl]

• C++17 has no std::hash_combine, so you’d replace with a small local helper (common combine formula) and drop <boost/functional/hash.hpp> includes.

This could be just borrowed from p4c.

[c8ef]

• C++17 has no std::hash_combine, so you’d replace with a small local helper (common combine formula) and drop <boost/functional/hash.hpp> includes.

This could be just borrowed from p4c.

If we consider using Abseil for flat map/set, we could leverage its hashing utilities as well.

[fruffy]

If we consider using Abseil for flat map/set, we could leverage its hashing utilities as well.

Would prefer to avoid spreading absl too much across the code base. It is a maintenance burden.