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"
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
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).
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.
--
/Jacob Carlborg
