Štěpán Němec <[email protected]> wrote: > On Sat, 02 Sep 2023 18:50:15 +0000 > Eric Wong wrote: > > > Štěpán Němec <[email protected]> wrote: > >> -Numerous optional modules are likely to be useful as well: > >> +Numerous other modules are likely to be useful as well: > > > > What is the reasoning for this change? > > "optional" is an important point to state, IMHO. > > Using "other" is more ambiguous, I think. > > We've now established that at least Inline::C is not optional on all > systems. Is that really the only case? (I mean, some of the modules > have "optional" again in their respective parentheticals: is that just > redundancy, or does it imply that the others are less optional?) Even > if it _is_ the only case, isn't saying "optional" misleading?
Perhaps the per-module "optional, for .." statements should be "only for ...". Aside from the new WIP -cindex; all public-inbox-* tools should all work fine without Inline::C. lei isn't likely running on most public-facing servers. In fact, all the components of public-inbox are optional depending on which pieces you want to use it for. The original public-inbox-* stuff (mda/learn/watch/WWW/httpd/CGI) should work w/o SQLite for v1 inboxes, even (I need to test before releases). IOW, I'm trying to keep installations that were configured and setup in back in 2014 working with no new dependencies. Honestly, I wish I could tell users a C compiler is required to make my life easier (heck, Varnish requires one); but gcc and clang are both gigantic; and tcc (while active) hasn't had a release in ages. Thanks.
