DIP11: Automatic downloading of libraries

Dmitry Olshansky dmitry.olsh at gmail.com
Tue Jun 21 03:04:08 PDT 2011


On 21.06.2011 13:07, Jacob Carlborg wrote:
> On 2011-06-21 00:30, Dmitry Olshansky wrote:
>> 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.olsh at gmail.com> wrote in message
>>>>> news:itn2el$2t2v$1 at 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.
>
> This is starting to get confusing. You're supposed to be passing an 
> arbitrary strings to the function and then _receive_ an instance to 
> the block.
>
>> What's so good about having to type all these name over and over again
>> without keeping track of how many you inadvertently referenced?
>
> You shouldn't have to repeat the name.
>
>> 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
>
> "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...


> In that case you wouldn't even have to care about "t" or that it even 
> exists an instance behind the since. It would just be syntax.
>
> You can have a look at how Rake and Rubgems do this:
>
> If you look at the Rake examples: 
> http://en.wikipedia.org/wiki/Rake_%28software%29 then a target would 
> work the same as a Rake task.
>

> Have a look at the top example of: 
> http://rubygems.rubyforge.org/rubygems-update/Gem/Specification.html
>
>> 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.
>
> Yes, version statements will be available as well.
>


-- 
Dmitry Olshansky



More information about the Digitalmars-d mailing list