On 2011-06-20 15:28, Andrei Alexandrescu wrote:
On 6/20/11 6:35 AM, Jacob Carlborg wrote:
On 2011-06-20 10:59, Dmitry Olshansky wrote:
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...
I had no idea that you could do that. It seems somewhat complicated and
like a hack. Also note that Orbit is currently written in D1, which
doesn't have __traits.
std.benchmark (https://github.com/D-Programming-Language/phobos/pull/85)
does that, too. Overall I believe porting Orbit to D2 and making it use
D2 instead of Ruby in configuration would increase its chances to become
popular and accepted in tools/.
Andrei
See my reply to Dmitry. BTW has std.benchmark gone through the regular
review process?
--
/Jacob Carlborg
