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.

1 files changed, 1 insertions, 1 deletions

diff --git a/src/main.c b/src/main.c
index 2d28700..efc9d12 100644
--- a/src/main.c
+++ b/src/main.c
@@ -78,7 +78,7 @@ typedef struct setup_t {
  */
 
 /* select video backend if not yet selected, then setup the selected backend. */
-static int setup_video(til_settings_t *settings, til_setting_t **res_setting, const til_setting_desc_t **res_desc, til_setup_t **res_setup)
+static int setup_video(const til_settings_t *settings, til_setting_t **res_setting, const til_setting_desc_t **res_desc, til_setup_t **res_setup)
 {
 	til_setting_t	*setting;
 	const char	*video;