Thanks for this. Given the somewhat cryptic explanation for $<TARGET_NAME:...> in the documentation, I’d allow myself to believe that it could be used as a placeholder to allow the order of inclusion of the targets files to not matter. Given the logical, rather than physical nature of export sets, this seemed like a reasonable feature to expect.
I’m incorporating modern CMake paradigms into a package that allows non-expert scientists to code their own software without becoming CMake experts, and a large part of that task is autogenerating the config and target files to do (almost) everything our scientists want without requiring hand-rolling. It’s relatively straightforward to detect a dependency from another export set and wrap it; less so to ensure that the contents of the export sets (as specified by non-experts) follow a strict dependency hierarchy.
Oh well, time to look for a different approach.
Thanks for taking the time to give me the bad news rather than letting me dig on in ignorance.