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.
The previous hledger-suite image was treated as a monolithic development
image that was never intended to be pulled from directly, at least
outside of the `dfi` build system.
hledger-suite has now been parsed out into separate build targets for
faster maintenance and development, with the final production image
being a massively slimmer "placeholder" image for the built binaries.
`hledger-suite:latest` can now be pulled from directly without pulling
the entire build system and related artifacts.
- 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.
- Prevents system upgrades from using Arch's `root` package
* Currently, their package does not build with C++20 support
- Updates remote image package artifact location
* Remote image's build artifact moved from /home/builder to /root
- Uses wildcard for local `root` package version
* Reduces maintenance since any remote bump should rebuild this module
8eb03f6d container: root: rootlogon: update the help process (Aaron Fiore)
9fec1b42 container: root: change base path, related refactor (Aaron Fiore)
273f2cef container: root: internal: update TODO re: c++23 (Aaron Fiore)
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
