"Dmitry Olshansky" <dmitry.o...@gmail.com> wrote in message news:itn2el$2t2v$1...@digitalmars.com... > On 20.06.2011 12:25, Jacob Carlborg wrote: >> On 2011-06-19 22:28, Dmitry Olshansky wrote: >> >>> Why having name as run-time parameter? I'd expect more like (given there >>> is Target struct or class): >>> //somewhere at top >>> Target cool_lib, ...; >>> >>> then: >>> with(cool_lib) { >>> flags = "-L-lz"; >>> } >>> >>> I'd even expect special types like Executable, Library and so on. >> >> The user shouldn't have to create the necessary object. If it does, how >> would the tool get it then? >> > If we settle on effectively evaluating orbspec like this: > //first module > module orb_orange; > mixin(import ("orange.orbspec")); > // > > // builder entry point > void main() > { > foreach(member; __traits(allMembers, orb_orange)) > { > static if(typeof(member) == Target){ > //do necessary actions, sort out priority and construct a > worklist > } > else //static if (...) //...could be others I mentioned > { > } > } > //all the work goes there > } > > Should be straightforward? Alternatively with local imports we can pack it > in a struct instead of separate module, though errors in script would be > harder to report (but at least static constructors would be controlled!). > More adequatly would be, of course, to pump it to dmd from stdin... >
Target would be part of Orb. Why not just make Target's ctor register itself with the rest of Orb?
