On Fri, 2015-02-06 at 13:35 +0000, Atila Neves via Digitalmars-d wrote:
> > 
[…]
> Which is why that's the language I want to express the build in. Methinks I have some code to write and some emailing to do with Soenke.

In this situation it would be good having many people working the same infrastructure. The time for lots of individual projects on this aspect of D is long gone.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Friday, 6 February 2015 at 13:35:43 UTC, Atila Neves wrote:
>> There are two important bits here (important for me):
>
> The approach I'm thinking of agrees 100% with your two important bits.
>
>> Anything that does not allow me to express such dependency chain in native straightforward manner without resorting to external scripts is simply not good enough. dub fails this, CMake fails this.
>
> CMake doesn't fail at this, it's just not easy. It's what add_custom_command is for.

"not easy" == "fails" in my opinion :)

>> D is only cross-platfrom scripting language we can rely on.
>
> Which is why that's the language I want to express the build in. Methinks I have some code to write and some emailing to do with Soenke.

Looking forward to hearing the outcome of this ^_^

On Friday, 6 February 2015 at 12:30:45 UTC, Daniel Murphy wrote:
> "Dicebot"  wrote in message news:listanyegqyanevsnvlv@forum.dlang.org...
>
>> D is only cross-platfrom scripting language we can rely on. This is probably biggest problem of make (apart from bunch of legacy syntax crap) - any real build system needs relatively complicated build rules for target transformation. However we can reasonably expect working D compiler from anyone wanting to compile D project - which is both perfectly cross-platform and does not request installation of any additional binaries.
>
> Sometimes you make a lot of sense.

That is purely accidental - hard to disappoint everyone all the time!

On Thursday, 5 February 2015 at 09:00:05 UTC, Atila Neves wrote:
> On Thursday, 5 February 2015 at 06:46:12 UTC, weaselcat wrote:
>> After reading this thread I think I'm the only person here who actually likes makefiles.
>>
>> Nothing ever feels as complete as a good old hand written makefile.
>
> Assuming you get it right. In my experience, this is analogous to saying "nothing ever feels as complete as manually managing memory". Humans shouldn't write Makefiles.
>
> As in the case of managing memory, I used to do that (hand-write Makefiles). I don't anymore because the alternatives are far better.
>
> Atila

And just as manual memory management, human must be able to manage it manually when required. Not in the general case, not as the default, but as a possibility.

This is what is wrong with most other build systems.

On 2015-02-05 05:43, Vladimir Panteleev wrote:

> Is it a default if you can't change it? Or can it be changed?

It can be changed. It's the "mainSourceFile" field [1].

> It is not a question of preference, it is a question of the behavior
> being incompatible with certain tools and workflows.

Sure it is, since this can be configured.

[1] http://code.dlang.org/package-format

-- 
/Jacob Carlborg

On 2015-02-04 23:00, Mike Parker wrote:

> Then you specify a specific version of the library as a dependency,
> rather than a version range.

No, this is not enough. The tool need to automatically track and lock the whole dependency graph. Example:

Project A:

"dependencies": {
  "b": "1.0.0"
}

Project B:

"dependencies": {
  "c": ">=1.0.0"
}

Even though you have locked your direct dependencies to a specific version doesn't mean that the dependencies have done so. Meaning, you can get arbitrary versions of indirect dependencies. You can start adding the indirect dependencies as direct dependencies but that defeats the point of a package manager.

I have explained this so many times in the Dub forum, why not locking the whole graph is a really, really bad idea.

I've experienced this myself many times with Ruby before it got Bundler which fixes this.

-- 
/Jacob Carlborg

On 2015-02-05 15:11, Sönke Ludwig wrote:

> There is a request to make this configurable and it's a rather trivial
> addition. I just don't have the time to implement all feature requests
> myself, which is basically why it is not implemented, yet.

Is the reason for putting it in the home directory to be able to share builds between packages?

-- 
/Jacob Carlborg

On Saturday, 7 February 2015 at 14:36:19 UTC, Jacob Carlborg wrote:
> On 2015-02-05 05:43, Vladimir Panteleev wrote:
>
>> Is it a default if you can't change it? Or can it be changed?
>
> It can be changed. It's the "mainSourceFile" field [1].

I don't see how this setting is at all relevant to the problem at hand.

On 2/7/2015 11:43 PM, Jacob Carlborg wrote:
> On 2015-02-04 23:00, Mike Parker wrote:
>
>> Then you specify a specific version of the library as a dependency,
>> rather than a version range.
>
> No, this is not enough. The tool need to automatically track and lock
> the whole dependency graph. Example:
>
> Project A:
>
> "dependencies": {
>    "b": "1.0.0"
> }
>
> Project B:
>
> "dependencies": {
>    "c": ">=1.0.0"
> }
>
> Even though you have locked your direct dependencies to a specific
> version doesn't mean that the dependencies have done so. Meaning, you
> can get arbitrary versions of indirect dependencies. You can start
> adding the indirect dependencies as direct dependencies but that defeats
> the point of a package manager.
>
> I have explained this so many times in the Dub forum, why not locking
> the whole graph is a really, really bad idea.
>
> I've experienced this myself many times with Ruby before it got Bundler
> which fixes this.
>

But apparently this can be done now with dub.selections.json.

On 2015-02-07 20:17, Vladimir Panteleev wrote:

> I don't see how this setting is at all relevant to the problem at hand.

Yes, sorry, "sourcePaths" and "importPaths" were the fields I was thinking about. Although I think "mainSourceFile" may be needed as well, otherwise dub will look for "app.d".

-- 
/Jacob Carlborg