fix: use system include syntax for all KokkosComm 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.

[cedricchevalier19]

Are we sure that the custom include_mpi.hpp is not needed anymore?

(Note that I am in favor of a more standard way to include mpi)

[dssgabriel]

I haven't touched it in the KokkosComm headers, but including MPI directly using the standard header works fine in tests.

[cedricchevalier19]

This is not necessary, and it can have some advantages to look for a file with a path relative to this file.

[dssgabriel]

I feel like it would be better to stay consistent and use the same include syntax everywhere. When looking at large "standard C++-style" libraries, they always use the system includes.

See e.g. :

• boost/hana: https://github.com/boostorg/hana/blob/master/include/boost/hana/append.hpp
• beman/execution26: https://github.com/beman-project/execution26/blob/main/include/beman/execution26/detail/basic_operation.hpp

What would be the advantages of keeping relative includes?

[cedricchevalier19]

We do not rely on INCLUDE_DIRS.

[devreal]

I agree with @dssgabriel. The moment a client code brings its own fwd.hpp KokkosComm will fall apart. Use proper namespacing for include paths.

[cedricchevalier19]

To me, it is quite the opposite, including a relative path force to use the correct file. Protecting collision with a directory is good but imperfect; if a user can have a KokkosComm/fwd.h in a path before ours, we will use it.

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#sf12-prefer-the-quoted-form-of-include-for-files-relative-to-the-including-file-and-the-angle-bracket-form-everywhere-else

It is not required by the standard that the compiler deals this way with quotes and brackets, but it was an observation. I was bracket-team in the past, and I think using quotes at the correct places can improve correctness and speed.

[cedricchevalier19]

Usually, we put std headers close to the top, like second after the associated header file if it is cpp.

[dssgabriel]

Similarly, large "standard C++-style" libraries seem to always include std headers after project headers (see examples shared previously).

[cedricchevalier19]

Some others do the opposite: https://google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes.

[cedricchevalier19]

We can (should?) keep it relative.