- Adds requirements to support auto-(un)load'ing, refactors
- Adds loader argument to unit tests and benchmarks
* Filters can now be passed as a loader argument
- Adds loader argument to Hash macro
* Factored out from shell caller
- Adds Pluggable auto-(un)load support
- Adds plugin dispatcher for interpreter
- Refactors to support new Pluggable system
- Updates usage help and improves documentation
Utilizes `libbitcoinkernel` for symbols and headers but also pulls from
non-kernel headers as needed (since current kernel design is a WIP).
See the code documentation in this commit for details.
Because of the nature of the interpreter, these headers should be
loaded/unloaded on an as-needed basis.
This commit is particularly useful for pluggables in that, if the
pluggable requires that the `dfi` API (or API-related implementations)
have certain preprocessor requisites fulfilled for the pluggable, the
API can now be compiled *after* the pluggable has been loaded but also
*before* the pluggable *requires* the use of the API (or API-related).
In other words, without this commit, a pluggable's `#define`s will be
useless *after* the API (or API-related implementations) is loaded and
compiled (at least not without an API reload, but that is not needed).
NOTE: this change does not affect `dfi`'s pluggable auto-(un|re)loading,
as the pluggable will have already been loaded prior to any other `dfi`
API compiling.
- Factors out (and deprecates) `Command`
- Deprecates certain free functions
- Adds better error handling
- Adds more free functions
- Refactors file handling
- Improves documentation
Notes on file loading (and general file handlers):
The interpreter command `.L` will load files but appears to not fail if
the file isn't source code or a library.
Calling `gSystem->Load()` will load a given library but not source file,
and appears to not accept paths (which will be needed for pluggables).
Because `gInterpreter->LoadFile("path")` will load either a source file
or library by given "path", and is consistent with `dfi`'s approach to
path handling, this function appears to be the winner (for now).
ROOT 6.38.00 brings LLVM 20 which errors (or ROOT's Cling errors) when
calling certain base CRTP template functions without a `this` pointer.
Resolves:
"error: call to non-static member function without an object argument"
NOTE: RandomImpl is not currently affected but is refactored for consistency.
The base path is now *outside* of the macro directory; allowing for a
more integrated view of `dfi`'s entire `root` system. This is more
apparent once running an interactive session where the expectation is
(more intuitively) that any path should be relative to 'src/root' and
not 'src/root/macro'.
The rationale for why this was in 'src/root/macro' to begin with stems
from how `root` (by default) will automatically load rootlogon.C in the
directory that `root` is started. This is causing more confusion than
not because `dfi`'s usage of `root` is not limited to macros.
These changes skirt the line between needing a major API bump and not
but, so far, appears to be on the side of *not*. However, the TODOs
noted for macro loading should be addressed prior to any API changes.
The old macros should *not* have been used in any example; as they
were intended for internal use only.
This was noted in Doxygen ...by not noting them as publicly consumable.
- Refactor using common types that were once internal
- Removes ancient macro approaches to C++20 solutions
- Changes `Exception` message type to use std::string
* std::string_view isn't worthwhile in this context
- Factor out respective common from macro and apply to all scopes
* `dfi::common`
* `dfi::macro::common`
* `dfi::plugin::common`
- Add deprecation warnings in `dfi::macro::common`
* Common functionality (not macro specific) is now in `dfi::common`
- Add convenience wrappers to inner common impl, where appropriate
* Allows for backwards compatibility
- Add/update/clarify code docs and Doxygen definitions
- Related refactoring
NOTE: all changes are backward compatible (no need to bump major).
- This is possible now that `dfi`'s ROOT build supports C++20
- No internal `dfi` API or impl changes are necessary
* This includes any Botan signatures
