If we bundle v6 in the build do we need/want a fallback. I need to look into what versions are available across all of the supported platforms.

This isn't about "bundling" the dep with the build so much as it is about supporting the versions of msgpack-cxx that are in the wild. The msgpack project, for better or worse, changed the way you depend on their library between v5 and v6, forcing all of their consumers to react to that change.

TheRock does in fact bundle msgpack (6.x) but that could easily just come from a distro which installs that version (I think this is where the issue was first discovered: on a distro that was shipping v6).

afaict, nothing that we used of msgpack-cxx changed materially between v5 and v6 aside from how you take the dep -- and other consumers of it seem to concur (see link).

(we can take out the part of the comment about "bundle in the build". That is specific to how TheRock operates)

I trust this is necessary, but it is difficult to understand why. Can you provide some context for posterity?

Sure. CMake builds are split into configure time and build time, with everything running at configure time being part of the former. Build time (i.e. things that run in make/ninja/etc) needs to not depend on environment variables provided in the configure time CMake invocation.

As it is presently, it is only possible to build a Tensile based project where you configure and build in the same shell environment, with the same variables set. This is not how multi-project builds (and various other kinds of automation) are done and is considered an anti-pattern.

In most projects, the configure side should fully resolve all needed tools to absolute paths and use them explicitly in the build phase vs relying on implicit build-time path based resolution. However, Tensile uses path based resolution extensively. I had a patch which attempted to plumb through absolute paths for everything, but it was quite intricate and something that should be considered for the future as its own thing (and the needed surgery is even worse in the hipblaslt version). As a partial step, since the project physically is not correct in its current state, this patch does the next best thing and at least preserves the configure-time PATH for use at build time when setting up custom commands. Without this, the build time PATH could be anything and the project fails to build unless if the build invocation is in the same shell environment.

I would recommend capturing this feedback in an issue for posterity and linking it in the source code. Ideally, in the future, we remove all PATH-based assumptions from Tensile and use explicit flags for tool locations, discovering them correctly at configure time.