Re: options.mk descriptions questions

[Greg Troxel <gdt%lexort.com@localhost>]

Kevin Bloom <kevin.bloom%posteo.net@localhost> writes:

> I've been working on porting a neat editor called Quick Emacs (qemacs)
> found in wip/qemacs and there are a few options that can be
> enabled/disabled with the configure script. I've included them all in
> an options.mk file and they appear to be working, however, upon
> running pkglint I get warnings that certain options do not have
> descriptions. This prompted me to think of a few questions that I
> haven't found solutions for in the pkgsrc manual:

options are indeed tricky.

> 1. What is the general rule of thumb for configure options? For
>    example, qemacs has options to use Xvideo, support plugins (for
>    adding your own modes in), support render HTML in the editor,
>    as well a tiny options that builds just the basic editor. Do I
>    include all of those options as options in options.mk? Or do
>    I enable/disable some -- and if so how do I pick?

The basic rule of thumb is that options are bad, but sometimes they are
better than not having options.  Binary packages are (in theory; not all
bulk builds comply) built with a near-empty mk.conf and thus with
default options.  At least, that's the rule for what's on
ftp.netbsd.org.  So, what matters most is what the default is.  Beyond
that, odd things can be be default-off, and people who are unusual can
choose to disable things that are default-on.

Ideally, there'd be separate packages or plugins.  If the dependencies
aren't that heavy, they might as well be on, either default on or not
even an option.

> 2. The tiny option disables all other options and generates a very
>    "basic" editor. Do I include this as an option or as a totally
>    seperate pkgsrc package? i.e. editors/qemacs-tiny

I find it irregular to have an option that controls other options.  I
don't think we really do that.

Yes, we can have another package, probably sharing Makefile.common.  But
the question is; do reasonable people actually want this, or is it
merely possible?  The world is too complicated, and if we can just
choose not to engage in some complexity, and nobody is harmed (or few
are harmed much), the rest of us not dealing with it might be a win.

One example is that we have emacs28-nox11 with almost no dependencies
and emacs28 with GUI.  The point is that people on headless systems
still want emacs to edit config files, and don't want gtk.  emacs is
popular enough that these two choices, which cover a lot of uses, are
warranted.

> 3. If I have options that don't have descriptions in
>    mk/defaults/options.description, how do I add them so the warning
>    goes away?

I think it's that you get someone to add them there, perhaps by just
putting an options.description file in the package with the lines.  This
doesn't happen that often so we don't have a formal plan for wip.

Looking at qemacs, my quick reaction is that there are too many options,
but I'm not sure that's fair.

It feels odd to have lots of options that force on x11.  Often when an
option is not on, we pass --disable-foo.  That won't work with this
style.

There is a concept of option groups, where there is a choice of picking
1 of N.  Otherwise, each option is present (on) or not present (off).

tiny feels like "just don't enable any of the options", in which case it
should not be listed.  A tiny build is one without any options enabled.

For each option, you should ask: what is the cost of enabling it, and is
there really anybody who reasonably wants to disable it?  For plugins,
I'd expect the build cost is very low, and you'd want it, so that
separate packages for plugins work.  I would expect you'd have to be
pretty extreme to want to turn it off to save code space.

Normally we have options when there is a dependency. Like adding qt5 to
something small.  For html, what is the cost of having it?  Would
anybody really need to save 20 kB of program text?  Just because
upstream lets you disable it doesn't mean pkgsrc should accept that
complexity.

For png, xshm, xv, the dependencies are confusing.  The normal approach
is to put the CONFIGURE_ARGS first, a blank line and then the bl3,
mirroring Makefile.  Not a big deal but I managed to read it wrong.

It more or less looks to me like x11 has to be on if several of the
others are.  As it is, with png, the png bl3 is included but libX11's is
not.  So:

  perhaps have a "if png is in the options var and x11 isn't, force on
  x11"

  perhaps similar logic, but error.

It feels like we must have this problem elsewhere.  I lean to error if
wrong and make people fix, and less magic, because magic is hard to
debug.

I would ask: once you add x11, how much does it hurt to add png and
xshmfence?  That's a combination of

  how many bytes of additional installed packages are required?

  how many bytes beyond what would have been anyway, average over many
  systems?

  how long does it take to build from source because of that, compared
  to what it takes anyway?

My gut feel is that once you go to X, because you are on a system that
does GUI things, libpng is just not going to hurt.  Overall that leads
to 

  always enable plugins (no option)
  always enable html (no option)
  having an x11 option that turns on all the x11 things.

and that's it.

Overall my advice is only add options when there's a clear win to
control it on/off.  Otherwise choose, leaning to having a feature rather
than not, as a little code you don't want is less painful than having to
rebuild.  Unless the code is objectionable/scary.  In the end, it
depends!