svn commit: r308655 - in head/games/xmoto: . files

[Dmitry Marakasov]

* Baptiste Daroussin (bapt at FreeBSD.org) wrote:

> > > Looks like these two should also be mentioned in OPTIONS_DEFINE.
> > 
> > Not adding them to OPTIONS_DEFINE preserves previous behaviour and I
> > don't think NLS and DOCS should be in the OPTIONS_DEFINE ever - they are
> > only meaningful to be set globally, and having them in individual ports
> > makes large builds much more painful, as a user has to set them for tons
> > of ports (even more painful without portmaster or knowing of
> > config-recursive).
> 
> My opinion on this is if you have already an OPTIONS_DEFINE it means that the
> dialog(1) will be shown anyway so it doesn't hurt to add NLS and DOCS to it.
> 
> if you do not have OPTIONS_DEFINE for something else then yes I can understand
> you don't want to bother users with dialog coming up all the time.

The said is true, but so it is inconsistent. What if there's single
`true' option in addition to DOCS/NLS and it's removed? Removing NLS and
DOCS this way has no real reason and is POLA violation wrt users who use
them. Leaving them, otoh, is a pain for users which never built this port.

I'd prefer some additional infrastructure to deal with it. The following
solution seem really convenient for me:

Introduce user-set list of options which are handled a bit differently:
when the port is build for the first time, and for config-recursive
(afaik, both are handled in config-conditional target), the dialog
is not brought up if ALL of options are in that list. They are still
shown in plain `make config'.

That way a user who doesn't care of NLS and DOCS should just set e.g.:

OPTIONS_IGNORE=	NLS DOCS

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3 at amdmi3.ru  ..:  jabber: amdmi3 at jabber.ru    http://www.amdmi3.ru