Since old-school OPTIONS knob support is long removed, I think we can do something about ugliness of the current OPTIONS_DEFINE[_arch]/OPTIONS_DEFAULT[_arch] pair of knobs.
I propose the following syntax (using now free-again OPTIONS knob, instead of several OPTIONS_DEFINE/OPTIONS_DEFAULT definitions). Consider this example:
PORTNAME= foo CATEGORIES= devel PORTVERSION= 42 # Existing code: look how verbose it is, yuck! #OPTIONS_DEFINE= DOCS X11 #OPTIONS_DEFINE_i386= MYSQL PGSQL #OPTIONS_DEFINE_amd64= MYSQL PGSQL #OPTIONS_DEFAULT_i386= MYSQL #OPTIONS_DEFAULT_amd64= PGSQL #OPTIONS_EXCLUDE_powerpc= X11 # Equivalent code (plus FOO/BAR): just a single line (yet still being perfectly readable) OPTIONS= DOCS FOO:on MYSQL/i386:on,amd64,arm PGSQL/i386,amd64:on X11!powerpc,arm,mips BAR:on!mips .include <bsd.port.mk>
Let's do some tests (on i386):
$ make -V OPTIONS_DEFINE DOCS FOO X11 BAR MYSQL PGSQL $ make -V OPTIONS_DEFAULT BAR FOO MYSQL $ make -V OPTIONS_DEFINE ARCH=amd64 DOCS FOO X11 BAR MYSQL PGSQL $ make -V OPTIONS_DEFAULT ARCH=amd64 BAR FOO PGSQL $ make -V OPTIONS_DEFINE ARCH=powerpc DOCS FOO BAR $ make -V OPTIONS_DEFAULT ARCH=powerpc BAR FOO $ make -V OPTIONS_DEFAULT ARCH=mips FOO
Pros: it's built on top of the existing framework; everything keeps working as before the patch applied. No ports need to be converted. If it's not your cup of tea, you can keep using the OPTIONS_DEFINE/OPTIONS_DEFAULT pair. I've been running with this patch for over a year now, and it survived all updates and never caused any conflicts, so I think it's safe enough to commit.
Cons: none! ;-)
We already widely use OPTIONS helpers, and foo:args syntax is quite common as well (e.g. in USES). This patch just takes another step to make our OPTIONS framework more awesome and easy to use.