Proposal: further OptionsNG improvements

[Alexey Dokuchaev]

On Fri, Jun 21, 2013 at 10:04:51AM +0200, Baptiste Daroussin wrote:
> Sorry it took time for me to reply, after we last talk about this, I
> thought a lot about this, and while in principe I do like the idea, I have
> a couple of concerns:
> 
> 1: this reduces lots of flexibility we now have with the new options
> framework, well at the least the patch should make sure it doesn't reduce it
> for instance, it should work properly with:
> OPTIONS_EXCLUDE and OPTIONS_SLAVE.

My current approach is to handle new "extended" syntax without interfering
with OptionsNG, and since OPTIONS_EXCLUDE or OPTIONS_SLAVE would not
contain any of that new :on or /${arch} stuff, I hope they would just work
as before. ;-)

> if should be able to handle properly the following situation:
> 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

Yes, it does handle it; in fact, hanlding this sort of several-lines ugly
constructs is one the pripary reasons why I want something more elegant.

I've cooked something up just now, take a look at the attached diff.  I've
only barely tested it, but it seems to work for a few of my hand-crafted
configurations.  It also handles known options groups (single/multi/etc.),
tested on www/firefox.

With the new syntax, the example above would simply become:

OPTIONS=	DOCS MYSQL/i386:on,amd64 PGSQL/i386,amd64:on X11!powerpc

Verified (old vs. new) by "make showconfig ARCH=... | md5".

Feedback welcome, as I might have missed some edge cases or a bug or two.

> This is things I haven't been able to imagine in a concise/understandable
> syntax like the one you are proposing, if we are able to do it then fine
> for me :)
>
> 2: I'm concern about the parsing performance, not that I have tested
> anything, but it just looks like it would be less performant for make(1)
> to parse properly all this, this should be measured to at least know the
> impact in the package building clusters and index building boxes once
> everything will be converted.

True, although I don't have idea how to measure it without converting
quite a number of ports first.  Perhaps an automated tool would help.

./danfe
-------------- next part --------------
Index: bsd.options.mk
===================================================================
--- bsd.options.mk	(revision 321792)
+++ bsd.options.mk	(working copy)
@@ -94,6 +94,43 @@
 
 PORT_OPTIONS+=	IPV6
 
+### Parse new OPTIONS knob (extended syntax)
+.for opt in ${OPTIONS:N*/*:N*!*}
+OPTIONS_DEFINE+=	${opt:C^:.*^^}
+OPTIONS_DEFAULT+=	${opt:M*\:on:S^:on^^}
+.endfor
+
+# Process known option groups
+.for otype in SINGLE RADIO MULTI GROUP
+.  for m in ${OPTIONS_${otype}}
+_${otype}_default:=		${OPTIONS_${otype}_${m}:M*\:on:S^:on^^}
+OPTIONS_DEFAULT+=		${_${otype}_default}
+OPTIONS_${otype}_${m}:=	${OPTIONS_${otype}_${m}:C^:.*^^}
+.  endfor
+.endfor
+
+# Process architecture-specific options
+.for opt in ${OPTIONS:M*/*}
+.  for arch in ${opt:C^.*/^^:S^,^ ^g}
+.    for defarch in OPTIONS_DEFINE_${arch:C^:.*^^}
+${defarch}+=	${opt:C^/.*^^}
+.    endfor
+.    for defarch in OPTIONS_DEFAULT_${arch:M*\:on:S^:on^^}
+${defarch}+=	${opt:C^/.*^^}
+.    endfor
+.  endfor
+.endfor
+
+# Process options unsupported on some architectures
+.for opt in ${OPTIONS:M*!*}
+OPTIONS_DEFINE+=	${opt:C^[:!].*^^}
+OPTIONS_DEFAULT+=	${opt:M*\:on!*:C^:.*^^}
+.  for arch in ${opt:C^.*!^^:S^,^ ^g}
+OPTIONS_EXCLUDE_${arch}+=	${opt:C^[:!].*^^}
+.  endfor
+.endfor
+###
+
 # Add per arch options
 .for opt in ${OPTIONS_DEFINE_${ARCH}}
 .if empty(OPTIONS_DEFINE:M${opt})
@@ -130,7 +167,7 @@
 ALL_OPTIONS:=	${OPTIONS_DEFINE:O:u}
 OPTIONS_DEFAULT:=	${OPTIONS_DEFAULT:O:u}
 
-# complete list
+# Complete list
 COMPLETE_OPTIONS_LIST=	${ALL_OPTIONS}
 .for otype in SINGLE RADIO MULTI GROUP
 .  for m in ${OPTIONS_${otype}}