Header files layout

[cedricchevalier19]

• Try to follow https://blogs.stonesteps.ca/1/p/64 for including header files.

• Also headers now have only one way dependencies between / and /impl.

• Some clean-up for CMake, like explicit list of files (*.h is notoriously bad for testing, for example, if we forget to add a new file, CMake configuration will still pass).

One question: since it is a new library, can we try to put header files in a KokkosComm directory?

User code will become:

#include <KokkosComm/KokkosComm.hpp>

I can add this to this PR or do a separate one.

[cwpearson]

I'm okay with putting things into a KokkosComm directory - @masterleinad do you know if Trilinos has an opinion on the structure of the headers?

[masterleinad]

I'm okay with putting things into a KokkosComm directory - @masterleinad do you know if Trilinos has an opinion on the structure of the headers?

I don't know why Trilinos would care. It doesn't matter for TriBITS but I don't know if there are any other Trilinos policies regarding subdirectories for header files vs prefixing (or both).

[cedricchevalier19]

I will update it after #14 is merged. It will be great to have the install tests!

[cwpearson]

I think I would also prefer:

• public headers can include things from impl/*
• impl/* CANNOT include things from public header

The main offender right now are

• KokkosComm::Req (used in the async MPI Impl::s and the packers)
• The concepts in impl/KokkosComm_concepts.hpp (defines some things not in the Impl:: namespace, oops, needs to be fixed.)

Maybe the things needed by Impl:: should actually be moved into Impl::, and then we can export them up into the public namespace:

namespace KokkosComm {
  using Impl::Req;
  using Impl::Invokable;
  ...
}

It's a bit redundant but it means

• the impl/* files that need the Req and concepts can use them without including a non-impl header, and then we can also have those APIs available outside of Impl::, which is what we're intending for the users.
• We don't have to play games with how includes are ordered and carefully watch out for circular dependencies

[cedricchevalier19]

Make sense, will do.

[cwpearson]

I think this will be somewhat (or entirely) resolved by #109

[cedricchevalier19]

Done in #109.