Nana Sakisaka

If you choose to do the migration yourself then that's fine, I won't take it personally. But I think this should be done by a single person due to the...

> libs/spirit_classic > libs/spirit_v2 > libs/spirit_x3 > > Is that what we want? Yes, this looks good to me. My suggestions: - Keep the current repository `boostorg/spirit` as-is for a...

> +1 for keeping the `spirit/` as the most modern Spirit.X3. Such move should give the users the signal to use it by default. I actually think this is a...

@pdimov Modern CMake applications expect libraries to set [`target_compile_features`](https://cmake.org/cmake/help/latest/command/target_compile_features.html) for naturally resolving minimal required C++ version. Spirit's `CMakeLists.txt` does not even have this level of support. Quoting my comment: >...

> What best practices does it not follow? [target_compile_features](https://cmake.org/cmake/help/latest/command/target_compile_features.html)

A "modular CMake system" intuitively suggests that the library is usable with `git submodule add` and `add_subdirectory`. For Spirit's case, it's: `git submodule add https://github.com/boostorg/boost.git && git submodule update --init...

@apolukhin This is how I gave up the constructive discussion with Peter 4 months ago. What do you think?

> This aside, let's get back to our renaming. Current consensus seems to be libs/spirit becomes latest and greatest (x3 for now), My original intent was that we could imply...

@djowel do you feel okay if the name "spirit" will going to point to the now obsolete library Classic? To be honest I feel like below two schemes are almost...

To be fair, I'm going to accept Joel's suggestion.