On 5/14/10 22:27, Graham Fawcett wrote:
> Hey again,
>
> On Thu, 13 May 2010 18:26:07 +0000, Graham Fawcett wrote:
>
>> Hi BCS,
>>
>> On Thu, 13 May 2010 17:31:34 +0000, BCS wrote:
>>
>>>> (b) derives the list of files by including all *.d files, except those
>>>> in directories named 'test' and except those which contain a main()
>>>> function.
>>>
>>> I'm thinking of how to make this work for the simple publication model
>>> of "Put it all out via HTTP/SVN/CVS/GIT/etc.". Anything that works for
>>> that should generalize well.
>>
>> Yes, agreed, 'simple publication' is what I hope to target. I'm
>> confident that issues like versioning, dependencies, and cataloguing can
>> be addressed once 'simple publication' is stable.
>>
>>> How about: Download files as needed to do imports from any local code
>>> but don't build them. Once you have copies of everything you need,
>>> build one lib per mapping rule that includes everything retrieved via
>>> that rule. At that point the name doesn't hardly matter at all. You can
>>> make it the FQN of the mapped package if you want it easy to interpret.
>>
>> If I follow you, then the naming of libraries (or pre-compilation of
>> libraries at all) is a non-issue: we download the necessary source
>> files, cherry-pick the ones needed for our project, and compile them
>> together. Or let the compiler do the cherry-picking for us: just make
>> sure everything is "included" properly when we invoke the compiler, and
>> it can discover all the necessary modules.
>>
>> I have a prototype that does roughly that already, but I was concerned
>> others might think the lack of a pre-compiled library was too hackish
>> (though I quite like it!). I think I'll proceed, and come back with some
>> sample code.
>
> OK, I'm back. :) I've put a copy of my prototype, here:
>
> http://github.com/gmfawcett/d-build
>
> The name 'd-build' is a bit misleading, but I have nothing better to
> call it.
>
> Currently it's a Python script -- sorry, I can still prototype a lot
> faster in Python -- but a D version will follow if there is interest.
>
> If you're interested, please visit the github link and read the README
> to get an idea of what it does (and doesn't do). If you look at the
> DEPS file, you'll see the amazing way that I specify a dependency on a
> specific verision of an external project.
>
> At this point, it's so simple that it's almost a "so what" -- but I
> think it is a promising start. Once the mechanics are down pat, the
> fun begins.
>
> Best,
> Graham

If you already have it written the script in python why do you use a shell script as the dependency file? You could use python for that as well and you wouldn't have problems on windows.

Hi Jacob,

On Sat, 15 May 2010 15:28:23 +0200, Jacob Carlborg wrote:
> 
> If you already have it written the script in python why do you use a shell script as the dependency file?

The dependency file isn't strictly a shell script, though the syntax looks the same. As you see, each line represents an external project; but the program reads each line and decides whether or not to execute it (via a system() call). It suits the needs of the moment, which are minimal. I'm not suggesting it's a good long-term format.

> You could use python for that as well and you wouldn't have problems on windows.

Sure. At this early stage, I don't want to make too many decisions about what technologies to use, what configuration formats, etc. The big questions of the day are about function and scope: are we headed in the right direction, where do we stop, and how do we separate our concerns?

On a side note, I've found that dranges, dstats and dcrypt (all from dsource.org) all work with a little bit of shoehorning (though I had to patch dcrypt to get it to compile under the latest D2: see http://github.com/gmfawcett/d-build/blob/dcrypt-play/DEPS). I would really like to hear of any other online D2 libraries that appear to work (and as importantly, ones that you'd like to work but don't).

Thanks for your input! Graham

BCS wrote:
> And to finish the thought; a system that only allows a program to ask for a single version is worse than one that doesn't allow any or allows many.


We've been around this block already several times :-(

On Sat, May 15, 2010 at 18:27, Graham Fawcett <fawcett@uwindsor.ca> wrote:

>
> On a side note, I've found that dranges, dstats and dcrypt (all from dsource.org) all work with a little bit of shoehorning (though I had to patch dcrypt to get it to compile under the latest D2: see http://github.com/gmfawcett/d-build/blob/dcrypt-play/DEPS). I would really like to hear of any other online D2 libraries that appear to work (and as importantly, ones that you'd like to work but don't).
>
>
Out of cursiosity, what kind of shoehorning for dranges? I see that you move the trunk inside a dranges directory. I admit putting the modules in trunk as that's what many other projects do. Would you prefer the files to be in .trunk/dranges/ or even directly in ./dranges/ ?


Philippe

Hi Philippe,

On Sat, 15 May 2010 23:03:54 +0200, Philippe Sigaud wrote:

> On Sat, May 15, 2010 at 18:27, Graham Fawcett <fawcett@uwindsor.ca> wrote:
> 
>> On a side note, I've found that dranges, dstats and dcrypt (all from dsource.org) all work with a little bit of shoehorning (though I had to patch dcrypt to get it to compile under the latest D2: see http://github.com/gmfawcett/d-build/blob/dcrypt-play/DEPS). I would really like to hear of any other online D2 libraries that appear to work (and as importantly, ones that you'd like to work but don't).
>>
> Out of cursiosity, what kind of shoehorning for dranges? I see that you move the trunk inside a dranges directory.

Yes, that was all I had to do for dranges.

> I admit putting the modules in trunk as that's what many other projects do. Would you prefer the files to be in .trunk/dranges/ or even directly in ./dranges/ ?

'trunk/dranges' would be fine -- keeping 'trunk' makes good sense for a Subversion project. For my purposes, any depth is okay, e.g. 'trunk/src/lang/d2/dranges' would also work. The key is that modules which belong to the 'dranges' package should exist in a 'dranges' directory.

What I'm doing is adding the parent of the 'dranges' directory to dmd's include-path. Then I just let DMD look up the module files using its own conventions (e.g. DMD expects that a module named foo.bar.baz will be defined in a file named foo/bar/baz.d). That's why I renamed trunk to dranges: it was the easiest way to honour the DMD naming convention.

Best,
Graham

On Sun, May 16, 2010 at 06:13, Graham Fawcett <fawcett@uwindsor.ca> wrote:

>
> 'trunk/dranges' would be fine -- keeping 'trunk' makes good sense for a Subversion project. For my purposes, any depth is okay, e.g. 'trunk/src/lang/d2/dranges' would also work. The key is that modules which belong to the 'dranges' package should exist in a 'dranges' directory.
>

OK. I admit switching to a package.module naming convention quite recently
(a month or so), so it's still a bit incomplete.
I should have done that.

>
> What I'm doing is adding the parent of the 'dranges' directory to dmd's include-path. Then I just let DMD look up the module files using its own conventions (e.g. DMD expects that a module named foo.bar.baz will be defined in a file named foo/bar/baz.d). That's why I renamed trunk to dranges: it was the easiest way to honour the DMD naming convention.
>
>
OK, got it. I'll add a dranges directory inside trunk today. And add a dranges dir in the downloadable .zip.That'a another alternative you have: look inside /download if there is something to get.

I'm following your project with interest, as  that'd be cool to have an easy-to-use tool to grap projects. I use dstats from time to time and just dumped the files into my own project file, but a command-line tool is better.

Philippe

BCS <none@anon.com> wrote:
> Hello BCS,
> 
> > Hello Walter,
> > >> BCS wrote:
> >> >>> My program imports lib A and B. Lib A imports lib C and asks
> > > > > > for
> >>> version "X". Lib B imports lib C and asks for version "!X". Who wins?
> >>> >> Compilation error.
> >> > Exactly. If there were a way for A to ask for X or Y and B to ask
> > > > for
> > Y or Z than the solution is easy: Y.
> > 
> And to finish the thought; a system that only allows a program to ask for a single version is worse than one that doesn't allow any or allows many.
> 

How does . NET work?  I recall versioning being an integral part of the design.

"Sean Kelly" <sean@invisibleduck.org> wrote in message news:1012172047295742031.093272sean-invisibleduck.org@news.digitalmars.com...
> BCS <none@anon.com> wrote:
>> Hello BCS,
>>
>> > Hello Walter,
>> > >> BCS wrote:
>> >> >>> My program imports lib A and B. Lib A imports lib C and asks
>> > > > > > for
>> >>> version "X". Lib B imports lib C and asks for version "!X". Who wins?
>> >>> >> Compilation error.
>> >> > Exactly. If there were a way for A to ask for X or Y and B to ask
>> > > > for
>> > Y or Z than the solution is easy: Y.
>> >
>> And to finish the thought; a system that only allows a program to ask for a single version is worse than one that doesn't allow any or allows many.
>>
>
> How does . NET work?  I recall versioning being an integral part of the design.

IIRC, When MS said that, it turned out they were really just talking about things like "depricated" keyword and designing the OO polymorphism so that changing one thing won't accidentally break something else (ex: manditory "override" keyword when overriding a base class function). I found it confusing too that they referred to that as "versioning".

On 5/17/10 20:35, Nick Sabalausky wrote:
> "Sean Kelly"<sean@invisibleduck.org>  wrote in message
> news:1012172047295742031.093272sean-invisibleduck.org@news.digitalmars.com...
>> BCS<none@anon.com>  wrote:
>>> Hello BCS,
>>>
>>>> Hello Walter,
>>>>>> BCS wrote:
>>>>>>>> My program imports lib A and B. Lib A imports lib C and asks
>>>>>>>> for
>>>>>> version "X". Lib B imports lib C and asks for version "!X". Who
>>>>>> wins?
>>>>>>>> Compilation error.
>>>>>> Exactly. If there were a way for A to ask for X or Y and B to ask
>>>>>> for
>>>> Y or Z than the solution is easy: Y.
>>>>
>>> And to finish the thought; a system that only allows a program to ask
>>> for a single version is worse than one that doesn't allow any or
>>> allows many.
>>>
>>
>> How does . NET work?  I recall versioning being an integral part of the
>> design.
>
> IIRC, When MS said that, it turned out they were really just talking about
> things like "depricated" keyword and designing the OO polymorphism so that
> changing one thing won't accidentally break something else (ex: manditory
> "override" keyword when overriding a base class function). I found it
> confusing too that they referred to that as "versioning".

Isn't it possible to put some version information in the binary? Found this: http://msdn.microsoft.com/en-us/library/4w8c1y2s.aspx