Conversation
Extract DataType, Dims, Params, Accuracy into ADIOSBaseTypes.h as a self-contained header with no internal dependencies. Rewrite PluginOperatorInterface as a standalone abstract class (no core::Operator inheritance) so external plugin operators need only include a single header and no longer link against adios2_core. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ource of truth Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
f2c8a0a to
fa18506
Compare
…tion Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
fa18506 to
15fc7ba
Compare
pnorbert
left a comment
There was a problem hiding this comment.
I approve this and vote for blowing away all that includes from the next release. So that we can have minor releases again.
|
A caveat though, I did want to install some headers in the past so that I could use useful helper functions and kwsys functions in my apps instead of copy-pasting their implementation all the time. |
|
kwsys we probably can't do much about, though it is handy. I will suggest that moving to C++17 so that we have std::filesystem might go a long way towards replacing that. WRT DimsToString, there's no reason why simple utility functions operating on the AdiosTypes or AdiosBaseTypes shouldn't have inline definitions in the appropriate .h file. |
This PR builds on the previous plugin operator proposal to also encompass plugin engines. The main change is to make plugin engines use the public ADIOS APIs rather than calling into core directly. This required some minor tweaks to the bindings classes, not to change their external visibility, but to let us call them from PluginEngine (the internal bridge to actual plug-ins). This is pretty much the biggest change. The changes to the actual plugin example pretty much consist of calling adios2:: rather than core::. There was also a minor change, moving ToString(Dims) to be inline in adiosTypes.h to avoid ToString depending upon core.
Note that this PR does stop installing all of our internal #include files. I included that here to make sure everything in the build/install tests works after that is done. In practice, we maybe want to do this piece-wise, introduce the new plugin interfaces in one release, then blow away those includes in the next major release.
Also Note, this PR is on top of the unmerged operator plugin PR, so it also includes all those changes in the diff. If we merge the other PR, this will get rebased.