I am thinking of introducing named parameters to metatarget rules along the lines
of the following:
lib program_options
: parsers.cpp
[ requirements <link>static ]
[ usage-requirements <define>BOOST_ALL_NO_LIB=1 ]
[ default-build <variant>release ]
[ description "Does something about dashes on command line" ]
[ license "BSL 1.0" ]
;
I expect the current syntax to remain available forever, but make this
new one the officially documented. You might note the example uses some
attributes ('description', 'license') that are not even available now,
and in fact adding a pile of optional attributes is the primary goal
here.
Internally, this will be implemented by introducing special classes
that are returned by rules like 'requirements' and specially processed
when encountered in the list of sources.
Before I go and implement this, would anybody be willing to critizie
my experiments in DSL design?
Named parameters would be a welcome feature! As would additional
optional parameters like you've listed here for description and license
(presumably these would become accessible in a build help system). I
think your proposal has a decent syntax, but I agree with Johan that
sticking with the project rule syntax would be optimal. If that's not
feasible to implement, I'm happy with what you proposed. Would
conditionals work as well?