On 21.06.2011 1:36, Jacob Carlborg wrote:
On 2011-06-20 22:45, Dmitry Olshansky wrote:
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.
I really don't like that the users needs to create the targets. The
good thing about Ruby is that the user can just call a function and
pass a block to the function. Then the tool can evaluate the block in
the context of an instance. The user would never have to care about
instances.
I'm not getting what's wrong with it. Your magical block is still
getting some _name_ as string right? I suspect it's even an advantage if
you can't type pass arbitrary strings to a block only proper instances,
e.g. it's harder to mistype a name due to a type checking.
What's so good about having to type all these name over and over again
without keeping track of how many you inadvertently referenced?
Taking your example, what if I typed name2 instead of name here, what
would be the tool actions:
target "name" do |t|
t.flags = "-L-lz"
end
Create new target and set it's flags? I can't see a reasonable error
checking to disambiguate it at all.
More then that now I'm not sure what it was supposed to do in the first
place - update flags of existing Target instance with name "name" ?
Right now I think it could be much better to initialize them in the
first place.
IMHO every time I create a build script I usually care about number of
targets and their names.
P.S. Also about D as config language : take into account version
statements, here they make a lot of sense.
--
Dmitry Olshansky
