On 2011-06-21 14:12, Dmitry Olshansky wrote:
On 21.06.2011 15:53, Jacob Carlborg wrote:
On 2011-06-21 12:04, Dmitry Olshansky wrote:
On 21.06.2011 13:07, Jacob Carlborg wrote:
"target" works like this:
1. You call "target" passing in the name of the target and a block
2. "target" then call the block passing in an instance of a Target
class (or similar)
3. In the block you then specify all the necessary settings you need
for this particular target.
You should only call "target" once for each target. So, if you pass in
"name2" instead of "name" you would create a new target. I haven't
figured out what should happen if you call "target" twice with the
same name.
Also note that this would be sufficient:
target "name" do
flags "-l-lz"
end
So it's a way to _create_ instances. I suspected there could be need to
add some extra options to existing. Imagine creating special version of
package, IMO it's better when all this extra is packaged at one place
not in every block.
BTW this doesn't look any better then possible D version:
spec = Gem::Specification.new do |s|
s.name = 'example'
s.version = '1.0'
s.summary = 'Example gem specification'
...
end
In any case there is now instance named spec, right? So user still have
to manage some variables...
No, no, no. Have you read my previous messages and the wiki? That
above syntax is used by Rubygems, Rake uses a similar and Orbit and
Dake will also use a similar syntax but will still be slightly
different. The concepts are the same, with calling a method and
passing along a block.
The syntax used by Orbit doesn't actually need blocks at all because
you can only have one package in one orbspec. The syntax will look
like this:
name "example"
version "1.0"
summary "Example gem specification"
Very sensible, no arguments.
Dake will have blocks in the syntax for its config files, this is
because multiple targets and tasks are supported within the same file.
The syntax will look like this:
target "<name>" do
flags "-L-l"
product "foobar"
type :executable
end
Yes, this is the one I'm not entirely happy with, admittedly because
it's a ruby script (and it's respective magic).
I just hope you can embed Ruby interpreter inside dake so that user need
not to care about having proper ruby installation (and it's correct
version too).
Of course, Ruby will be embedded. I already have this working in Orbit.
I'm very careful when choosing the dependencies my application/tools
depends on. Another reason I'm not happy about switching to D2, then it
would depend on libcurl.
In this case, <name> would refer to a single D file or a directory
with multiple D files. If you want to have settings for multiple
targets then you just put that code outside any of the blocks, at the
global scope (or pass a block to a method name "global", haven't
decided yet).
Good so far.
And similar for tasks:
task "foo" do
# do something
end
A task is just some code you can run from the command line via the tool:
dake foo
As you can see, no variables and no instances for the user to keep
track of. Seems that I actually do need to write down a complete
specification for these config/spec files.
I'm still looking for a clean version statements... but I'll just have
to wait till you have the full spec I guess.
if version.linux || version.osx
#
end
This allows to use versions just as bool values.
--
/Jacob Carlborg
