Detect accidently using multiple camp versions

[MrBurmark]

Occasionally I shoot myself in the foot by accidentally mixing multiple versions of camp, either in a single translation unit or in different libraries. Is it possible to detect these cases and issue a compile or link time error?

[mcfadden8]

FYI,

We have an implementation in Umpire that attempts to address this by causing an build/link-time error if an attempt is made to use multiple versions of Umpire. For reference, the relevant implementation may be found here: https://github.com/LLNL/Umpire/blob/develop/src/umpire/Allocator.inl#L21 and https://github.com/LLNL/Umpire/blob/develop/src/umpire/config.hpp.in#L34-L55

[trws]

The trick for camp is making it work without a compiled component.

@MrBurmark, can you give an example of how the single TU issue would come about? I'm not sure how that one's possible.

When it comes to cross-library, we should be able to detect it by making some symbol or other incompatible across versions. The camp::tuple would be a good candidate for that, have an inline namespace around it depend on the camp version such that tuples from different camp versions can't link for example. I'm not sure if that would really cover what you want though.

[MrBurmark]

It would be nice if the error mentioned something about the version. Could the whole thing could be inline namespaced with a version? I'm not sure I understand why that fail to link.

Single TU is less of an issue and more of something I'd like to detect. I have accidentally mixed versions of RAJA and umpire built with different camp versions before. So its more like I've used headers from a library built with a different camp with the wrong camp. The header guards and include order ensures only one is used so it may not be possible to detect anyway from within camp.

[trws]

We can embed the version in the name of the inline namespace. It wouldn't fail to link within a single TU, but if the tuple or other type is used in an interface that crosses TUs then it would fail to link (which is where this kind of issue usually hides but causes major breakage later).

That one is trickier, and would probably best be handled by adding a tiny compiled component and doing what @mcfadden8 shows umpire doing. That would detect it at link time at least, and show the two versioned symbols that caused it, but there's no way I can think of to get it during compilation short of generating a header that gets used inside each including project that would have no other job.