refactor!: harmonize syntax & include order of headers

[dssgabriel]

Fixes #120.

Removes all instances of relative paths in favor of system include-style syntax: <KokkosComm/...>

I think we can also get rid of the KokkosComm/mpi/impl/include_mpi.hpp header?

[dssgabriel]

Follow-up questions (may be left for another PR):

• do we want to follow standard C++ library design guidelines and use include instead of src as the base directory (since we're a header-only library)?
• similarly, do we want to use details subdirs/namespaces instead of impl for implementation details?

See the Beman Project — an effort to support open-source, community-driven implementations of standard C++ paper proposals — example library structure for more guidance: https://github.com/beman-project/exemplar

I understand that I may be nitpicking here, feel free to dismiss the ideas if you think they're irrelevant to KokkosComm! 🙂

[cedricchevalier19]

It is not clear that we will be a header-only library forever. It might be interesting to have some precompiled parts to hide some internals in our compiling units.

As for impl, it is standard practice for kokkos projects, so I think we should keep it.

[cedricchevalier19]

A simpler PR with changes focused on the tests and core files where the relative include is upward will be better suited to solve the issue.

[dssgabriel]

Finally coming around to finish this PR!

We now follow C++ Core Guidelines and Google C++ Style Guide for the order of included headers.

Headers are included in the following order, and separated by a blank line between each level:

1. Associated header (as KokkosComm is--currently--a header-only library, we are not concerned by this);
2. C system headers;
3. C++ standard library headers;
4. External library headers (priority is given to C-based libraries, e.g. mpi.h comes before Kokkos_Core.hpp);
5. KokkosComm headers:
   • Base path with <> for any header that is "less deeply nested" than the current header (e.g. <KokkosComm/concepts.hpp>);
   • Relative path with "" for headers that are at the same level or "more deeply nested" than the current header.
6. KokkosComm implementation details headers (same syntax rules as the prior level).

[nicoleavans]

Assuming mpi.hpp will be renamed and semantic blocks will be used to separate header files in KokkosComm.hpp (as already indicated in comments), I fully support these changes.

[dssgabriel]

An important question while we are at it: should KokkosComm "export" Kokkos Core? Currently, we include Kokkos_Core.hpp in our top-level KokkosComm/KokkosComm.hpp header, and I don't think we should. We may use it internally but it shouldn't be part of what we directly expose when including KokkosComm, IMHO.

What do you think @cedricchevalier19 @cwpearson @nicoleavans ?

[cedricchevalier19]

An important question while we are at it: should KokkosComm "export" Kokkos Core? Currently, we include Kokkos_Core.hpp in our top-level KokkosComm/KokkosComm.hpp header, and I don't think we should. We may use it internally but it shouldn't be part of what we directly expose when including KokkosComm, IMHO.

It is a very good point. Ideally we should not export Kokkos Core, but if we do not do this we are not self usable anymore.

I think we can try to get rid of it and see if it is too annoying for our prospective users.

[dssgabriel]

Once merged, closes #119 and #114 as well.

[cwpearson]

Thanks @dssgabriel! You also raise some good questions. I don't think we can practically avoid exporting Kokkos_Core.hpp because we're going to have some concepts as part of our interface that are specialized on Kokkos::View.

[dssgabriel]

@cwpearson

we're going to have some concepts as part of our interface that are specialized on Kokkos::View

Isn't it sufficient to export Kokkos_Core.hpp within our headers (e.g. KokkosComm/concepts.hpp) but not explicitly in our main KokkosComm/KokkosComm.hpp entry point?

Since tests are passing without it in our main header, I think we can merge it like this and revert back to including it if that's too annoying for our users.