On 20.06.2011 23:39, Nick Sabalausky wrote:
"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?
Nice thinking, but default constructors for structs?
Of course, it could be a class... Then probably there could be usefull
derived things like these Executable, Library, etc.
--
Dmitry Olshansky
