Add std::array-like class

[adayton1]

• Add camp::array as a portable alternative to std::array
• Add portable testing infrastructure
• Register gtests with ctest for filtering (which requires CMake 3.10)

[artv3]

I was recently asked if we will now expect users to call camp directly in their applications. Will we? or do we think we will add camp features under a raja namespace?

[rhornung67]

I was recently asked if we will now expect users to call camp directly in their applications. Will we? or do we think we will add camp features under a raja namespace?

Perhaps, once we land on a unified RAJA Portability Suite project, we should move things we expect users to have easy access to to a 'RAJA' namespace, using aliases, etc. We should discuss as a team.

[trws]

The traditional thing has been to wrap everything in raja namespace, but I think the big decision will be whether we do it for desul or not, and for some things here. We could make it so that camp things can be re-exported or only exported into a different namespace, but I'm not sure which is better to be honest.

[trws]

This looks pretty slick @adayton1, let me know when you're ready for a review and discussion.

[adayton1]

This looks pretty slick @adayton1, let me know when you're ready for a review and discussion.

It's ready for review!

[rhornung67]

A few questions about comparison operators. I may be misunderstanding something here.

[adayton1]

@rhornung67 @long58 I've modified the comparison operators. operator< now matches the implementation in std::lexicographical_compare (https://en.cppreference.com/w/cpp/algorithm/lexicographical_compare) and all the other operators are implemented in terms of operator< or operator=.

Alternatively, I'm not really sure if there's a benefit to having comparison operators besides == and !=. I could potentially remove the others.

[rhornung67]

@adayton1 FWIW, we use this macro in RAJA to handle the various back-end cases https://github.com/LLNL/RAJA/blob/develop/include/RAJA/util/macros.hpp#L143

[adayton1]

I will look into that, but I don't want that to hold up this pull request.

[rhornung67]

@rhornung67 @long58 I've modified the comparison operators. operator< now matches the implementation in std::lexicographical_compare (https://en.cppreference.com/w/cpp/algorithm/lexicographical_compare) and all the other operators are implemented in terms of operator< or operator=.

Alternatively, I'm not really sure if there's a benefit to having comparison operators besides == and !=. I could potentially remove the others.

For consistency with std::array, I think you should keep them.

[rhornung67]

Thank you @adayton1

[adayton1]

The Docker rocm tests are failing, I think probably because the machine doesn't have any AMD GPUs. Should I turn off the testing and just do the build? Or maybe I could try to build in a filter so only the host tests run.

I also noticed that the docker nvcc builds don't actually build with nvcc - they are host only builds.

[rhornung67]

The Docker rocm tests are failing, I think probably because the machine doesn't have any AMD GPUs. Should I turn off the testing and just do the build? Or maybe I could try to build in a filter so only the host tests run.

I also noticed that the docker nvcc builds don't actually build with nvcc - they are host only builds.

I believe all of our projects that run CI on cloud services only build and do not run anything for GPU jobs. Was it running before your PR? If so, I don't know how that would work.

[adayton1]

The Docker rocm tests are failing, I think probably because the machine doesn't have any AMD GPUs. Should I turn off the testing and just do the build? Or maybe I could try to build in a filter so only the host tests run.
I also noticed that the docker nvcc builds don't actually build with nvcc - they are host only builds.

I believe all of our projects that run CI on cloud services only build and do not run anything for GPU jobs. Was it running before your PR? If so, I don't know how that would work.

Yeah, they do run tests. I'm not sure how that was working before, either. The nvcc builds were actually host only, so tests would have run fine there. But the rocm one would have been broken. For now, I've filtered out all the tests that run code on GPUs. We'll want to clean up this CI in a follow on merge request.