diff options
author | Vito Caputo <vcaputo@pengaru.com> | 2023-05-07 20:05:38 -0700 |
---|---|---|
committer | Vito Caputo <vcaputo@pengaru.com> | 2023-05-11 15:18:02 -0700 |
commit | a409d9fd5d861d52dca0e4ed33416a49b00ae2d9 (patch) | |
tree | 64ca214e83102051c265c5cb1006de6b168308c4 /src/Makefile.am | |
parent | f4e29c7923960d3cc6af73b3c66498cf9b2d6f38 (diff) |
setup: constify settings passed to setup_func
setup_func isn't formally defined for libtil, but
setup_interactively() defacto establishes it and
til_module_t.setup() reflects the same signature and calling
convention except with til_settings_t constified.
This change makes them all consistent in this regard, but there
should probably be a formal typedef added for the function.
The reason for constifying this is I don't want setup functions
directly manipulating the settings instance. In the case of
rototiller::setup_interactively() we ensure the stdio-based
interactive setup is always the side doing the manipulation of
the settings. For a libtil-user like glimmer, it's slightly
different beast with GTK+ in the loop, but by preventing the
setup_funcs from messing directly with the settings (instead
having to describe what they want done iteratively), the
front-end always gets its opportunity to maintain its state while
doing the described things.
Of course, this is mostly a lie, and within libtil the constified
til_settings_t gets cast away to modify it in places. But
keeping that limited to within libtil is tolerable IMO. We just
don't want to see such casts in module code.
Diffstat (limited to 'src/Makefile.am')
0 files changed, 0 insertions, 0 deletions