On Monday, 2 February 2015 at 16:42:03 UTC, Dicebot wrote:
> On Monday, 2 February 2015 at 16:26:45 UTC, Atila Neves wrote:
>> This thread has just made me decide to write a D build system, in D and configured in D that builds on dub and its packages intead of reinventing the wheel. I might ask the community for inputs on requirements. Maybe this will be my DConf 2015 submission.
>
> I have recently been experimenting with meta-dlang repository (to aggregate exisiting ones) and using D scripts instead of makefiles for uniform cross-platform build experience.
>
> That quickly has made me wanting to get something like `std.make` into Phobos - small utility module that would allow declaratively defining target tree + shell scripts similar to makefiles, as well as set of small nice shell wrappers (like one that effectively enables `set -e` for called commands). Having such module in standard library would make it much easier to replace makefiles with a quick D scripts and potentially build a robust build system on top.

I have ideas that go beyond this, but this is useful input. I wonder how to proceed now about gathering actual requirements from D devs and seeing which ones are important.

Atila

On Monday, 2 February 2015 at 10:13:27 UTC, Vladimir Panteleev wrote:
> On Monday, 2 February 2015 at 10:09:00 UTC, Joseph Rushton Wakeling wrote:
>> Well, as long as the requirements are expressed in the form,
>>
>>    "package-name": ">=1.2.3"
>
> This will allow Dub to pick a new major version with incompatible changes, no?

Yes, I would advise never to use >=, especially for a library.
http://p0nce.github.io/d-idioms/#Never-use-%3E=-for-dependencies

On Monday, 2 February 2015 at 13:10:56 UTC, Mike Parker wrote:
> On 2/2/2015 7:13 PM, Vladimir Panteleev wrote:
>> On Monday, 2 February 2015 at 10:09:00 UTC, Joseph Rushton Wakeling wrote:
>>> Well, as long as the requirements are expressed in the form,
>>>
>>>    "package-name": ">=1.2.3"
>>
>> This will allow Dub to pick a new major version with incompatible
>> changes, no?
>
> "~>1.2.3"
> This will constrain it to the range of 1.2.3 ... 1.3.0.

Better yet, "~>1.2" will constrain from 1.2.0 to 2.0.0 which means it will stop updating when incompatible changes are released.

On Monday, 2 February 2015 at 16:42:03 UTC, Dicebot wrote:
> On Monday, 2 February 2015 at 16:26:45 UTC, Atila Neves wrote:
>> This thread has just made me decide to write a D build system, in D and configured in D that builds on dub and its packages intead of reinventing the wheel. I might ask the community for inputs on requirements. Maybe this will be my DConf 2015 submission.
>
> I have recently been experimenting with meta-dlang repository (to aggregate exisiting ones) and using D scripts instead of makefiles for uniform cross-platform build experience.
>
> That quickly has made me wanting to get something like `std.make` into Phobos - small utility module that would allow declaratively defining target tree + shell scripts similar to makefiles, as well as set of small nice shell wrappers (like one that effectively enables `set -e` for called commands). Having such module in standard library would make it much easier to replace makefiles with a quick D scripts and potentially build a robust build system on top.

https://github.com/abscissa/scriptlike

On Monday, 2 February 2015 at 09:25:31 UTC, Mathias LANG wrote:
> On Monday, 2 February 2015 at 09:03:56 UTC, Vladimir Panteleev wrote:
>>
>> Is that so? Won't a security fix entail a version bump, requiring a change in the requirements file of the parent project? Also, does Dub really check for updated versions of libraries online, every time a project is built?
>>
>
> It does.
> You have a broad range of options for specifying which version to use.
> http://code.dlang.org/package-format#version-specs
> If you use Semver correctly, it's a great benefit.

Pretty much. If you don't use version ranges, you fall into the diamond dependency problem.

A => B => C v1.2.3
A => D => C v1.3.6

Even if C v1.2.3 and v1.3.6 are API-compatible, you can't build A if you don't control both B and C.

So, version ranges are necessary for an ecosystem of libraries.

On Monday, 2 February 2015 at 16:56:56 UTC, ponce wrote:
> A => B => C v1.2.3
> A => D => C v1.3.6
>
> Even if C v1.2.3 and v1.3.6 are API-compatible, you can't build A if you don't control both B and C.
>
> So, version ranges are necessary for an ecosystem of libraries.

Erratum: if you don't control both B and D*

On Monday, 2 February 2015 at 16:56:52 UTC, Tobias Pankrath wrote:
> https://github.com/abscissa/scriptlike

Yes, there is plenty of good stuff there and it can be used as inspiration. Though AFAIK it misses that bit about defining action/target tree and automatically exposing it to CLI (which is not something std.getopt helps with)

Getting it into Phobos is important though as that would mean that any project that uses D for scripting would only need most basic working D installation for bootstrapping - no controversy about dependency management or installation of extra tools.

I have started poking too many things at once and don't want to commit myself to implementing such a module but if something is willing to use Nick Sabalausky as base and create Phobos proposal from it, I will gladly help in both implementation and pushing it through formal review queue.

On Monday, 2 February 2015 at 16:56:52 UTC, Tobias Pankrath wrote:
> On Monday, 2 February 2015 at 16:42:03 UTC, Dicebot wrote:
>> On Monday, 2 February 2015 at 16:26:45 UTC, Atila Neves wrote:
>>> This thread has just made me decide to write a D build system, in D and configured in D that builds on dub and its packages intead of reinventing the wheel. I might ask the community for inputs on requirements. Maybe this will be my DConf 2015 submission.
>>
>> I have recently been experimenting with meta-dlang repository (to aggregate exisiting ones) and using D scripts instead of makefiles for uniform cross-platform build experience.
>>
>> That quickly has made me wanting to get something like `std.make` into Phobos - small utility module that would allow declaratively defining target tree + shell scripts similar to makefiles, as well as set of small nice shell wrappers (like one that effectively enables `set -e` for called commands). Having such module in standard library would make it much easier to replace makefiles with a quick D scripts and potentially build a robust build system on top.
>
> https://github.com/abscissa/scriptlike

Are you the owner of this code?  If you are could you put some examples of it in the readme/api docs.  Examples that demonstrate the use cases that this library makes very easy.

On Monday, 2 February 2015 at 18:29:40 UTC, Jonathan Marler wrote:
>>> scripts and potentially build a robust build system on top.
>>
>> https://github.com/abscissa/scriptlike
>
> Are you the owner of this code?  If you are could you put some examples of it in the readme/api docs.  Examples that demonstrate the use cases that this library makes very easy.

Nope.

On Monday, 2 February 2015 at 18:29:40 UTC, Jonathan Marler wrote:
>> https://github.com/abscissa/scriptlike
>
> Are you the owner of this code?  If you are could you put some examples of it in the readme/api docs.  Examples that demonstrate the use cases that this library makes very easy.

abscissa is Nick Sabalausky