Am 02.02.2015 um 12:00 schrieb Manu via Digitalmars-d:
> On 2 February 2015 at 18:09, Vladimir Panteleev via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy wrote:
>>
>> [snip]
>
> I agree with basically everything you said.
> I'll add, I have no use for (and no way to use) dub because I depend
> on cross-language build configurations.
> If my D project depends on a C lib, then what am I supposed to do to
> make dub useful for me?

I agree that this should have the highest priority on the feature list, especially considering all the effort that goes into improving the C++ interface. My plan was to get something useful for a pure D ecosystem first and then explore the more advanced use cases.

Am 02.02.2015 um 09:09 schrieb Vladimir Panteleev:
> Even if I had faith that dub was a perfectly polished piece of software,
> it doesn't solve any problems I have with building D programs, and in
> fact would make said task more complicated. Here's why.
>
> (...)

I think I've already answered most of the points in other replies, so I'm just going to skip to the final list of claims.

> So, in order to start using Dub, I'd need to:
>
> - restructure the directory layout of my library (breaking change)
Not true. Use "sourcePaths" and "importPaths" to configure the package as appropriate.

> - update all projects which use this library to use Dub instead
Not true. Adding a dub.json will probably not break any dependent projects.

> - give up quick syntax checking
Not true. Use path based dependencies or "add-path"/"add-local" to reference dependencies wherever you want.

> - give up commit-granularity versioning
True. However, this can be fixed. Direct GIT/HG support is already on the list of nice to have features.

> - begin maintaining JSON configuration files
Well, for most projects that would mean writing a tiny JSON file once and never touch it again. If you commit to it, you can of course stop maintaining a D build script, so I'm not sure how much of an argument this is.

> - begin versioning libraries by hand
A good thing, IMHO! Commit hashes alone have no semantical meaning, which is problematic for public libraries for many reasons. For private libraries things can be different and additionally supporting commit based dependencies may be good to have.

> - install Dub on all my computers, servers, and virtual machines
Yes. You could then skip installing GIT, though ;)

>
> No thanks.
>
> I could invest time in improving Dub to fix or ameliorate some of the
> above points, but I don't see a compelling reason to. In fact, I think
> we should integrate rdmd into dmd - dmd clearly already knows which
> source files participate in compilation, as all rdmd does is basically
> take dmd's output and feed it back to it. This will greatly speed up
> compilation, too.
>
> Change my view.

DUB in it's current form focuses on three primary points:

 - Building a package should "just work", including building the dependencies (mind the bugs)
 - Provide a public package registry with minimal effort to register and maintain packages
 - Minimize the barrier to entry for "usual" projects

The more advanced use cases, such as interfacing with other languages, will be the focus of future development. The initial primary goals above have been chosen to be most helpful for language newcomers, so that we get the maximum gain for the language ecosystem as a whole (in terms of growth and barrier to entry). More advanced users and users with legacy code bases are of course just as important in the long run, so those concerns need to be addressed now, too (as developer resources permit).

Regarding a DMD integrated version of RDMD, I always have thought the same. If that were the case, using a recursive build strategy would definitely be the mode of operation for DUB, too. The reason why it works differently today is simply that it has to support all the build systems/project file formats of the supported IDEs/build systems and most of them work in a classic C++-like way with a list of source files.

IDE support was also one of the primary goals, because there are large groups of developers that exclusively develop with IDEs and forcing them to the command line would simply make it much more likely that they won't use D at all. On top of that I personally very much like the ability to quickly build with Visual Studio to use its graphical debugger.

Am 02.02.2015 um 15:59 schrieb ketmar:
> On Mon, 02 Feb 2015 14:18:47 +0000, Tobias Pankrath wrote:
>
>> At least I don't expect Dub to support every single language out there
>> natively.
>
> that's why other build tools allows to manually specify dependencies and
> commands as a last resort. but dub can't.
>

Such as "preBuildCommands" [1]?

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

On Thu, 05 Feb 2015 15:11:50 +0100, Sönke Ludwig wrote:

> Am 02.02.2015 um 15:45 schrieb ketmar:
>> On Mon, 02 Feb 2015 14:36:00 +0000, Mathias LANG wrote:
>>
>>> I couldn't disagree more, but I understand how frustrating dub can be. I also had to adapt my workflow to it.
>>
>> and sometimes it's plain unusable. it insists on batch builds, and i have three or so modules which eats ~2GB of RAM each on compiling (yep, CTFE- parsing-heavy). it works with separate compilation, but batch compilation just cannot be done on my x86 box.
>>
>>
> --build-mode=singleFile

thanks, it's slightly better than nothing. ;-) yet it still insisting on rebuilding each module, thus triggering lenghty regenerations. even for libraries, where convenient tool is able to rebuild only one module and replace that single object file in library.

On Thu, 05 Feb 2015 15:51:23 +0100, Sönke Ludwig wrote:

> Am 02.02.2015 um 15:59 schrieb ketmar:
>> On Mon, 02 Feb 2015 14:18:47 +0000, Tobias Pankrath wrote:
>>
>>> At least I don't expect Dub to support every single language out there natively.
>>
>> that's why other build tools allows to manually specify dependencies and commands as a last resort. but dub can't.
>>
>>
> Such as "preBuildCommands" [1]?
> 
> [1]: http://code.dlang.org/package-format#build-settings

nope. such as "'a' depends of 'b', 'b' depends of c, here are commands to generate 'a' and 'b', don't call that commands if it's not necessary". "...always before the project is built" is not what i excepting from decent build tool.

On Thu, 05 Feb 2015 14:48:12 +0100, Sönke Ludwig wrote:

> Am 03.02.2015 um 21:08 schrieb ketmar:
>> On Tue, 03 Feb 2015 19:43:53 +0100, Martin Nowak wrote:
>>
>>> On 02/03/2015 09:51 AM, ketmar wrote:
>>>> 'cause it really sux as a build tool.
>>>
>>> Not getting into any of the lengthy discussions of yours, but 'it sux' isn't really helping anyone to improve it.
>>
>> repeating the reasons why it sux doesn't help too. this thread alone has some of them, including inability to do separate compilation (and the reason why this can be needed).
> 
> Separate per package (the default)? Separate by D module
> (--build-mode=singleFile)? Something else?

yes, incremental rebuilds, please. even for simple project with two modules dub is not able to do incremental rebuilds:

=== source/app.d ===
import std.stdio;
import mymod;

void main () {
  writeln(test);
}

=== source/mymod.d ===
module mymod;

int test () { return 42; }

% dub --build-mode=singleFile
Building _00 ~master configuration "application", build type debug.
Compiling using dmd...
Compiling source/app.d...
Compiling source/mymod.d...
Linking...
Running ./_00
42

so far, so good.

touch source/app.d
% dub --build-mode=singleFile
Building _00 ~master configuration "application", build type debug.
Compiling using dmd...
Compiling source/app.d...
Compiling source/mymod.d...
Linking...
Running ./_00
42

??? i didn't modified "mymod.d"! why it is rebuilding it?! 'cmon, it's in no way better than a simple shell script that just executes "dmd -c" for each file and then links the results.

Am 02.02.2015 um 09:09 schrieb Vladimir Panteleev:
> On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy wrote:
> 1. rdmd
>

BTW, there is one thing about RDMD that can be a real issue and one that is not easily solved without integrating its functionality directly into DMD: It doesn't track local and string imports. This is the main reason why I haven't personally used it since a while, although it is directly supported with "dub --rdmd".

Am 05.02.2015 um 16:01 schrieb ketmar:
> On Thu, 05 Feb 2015 14:48:12 +0100, Sönke Ludwig wrote:
>
>> Am 03.02.2015 um 21:08 schrieb ketmar:
>>> On Tue, 03 Feb 2015 19:43:53 +0100, Martin Nowak wrote:
>>>
>>>> On 02/03/2015 09:51 AM, ketmar wrote:
>>>>> 'cause it really sux as a build tool.
>>>>
>>>> Not getting into any of the lengthy discussions of yours, but 'it sux'
>>>> isn't really helping anyone to improve it.
>>>
>>> repeating the reasons why it sux doesn't help too. this thread alone
>>> has some of them, including inability to do separate compilation (and
>>> the reason why this can be needed).
>>
>> Separate per package (the default)? Separate by D module
>> (--build-mode=singleFile)? Something else?
>
> yes, incremental rebuilds, please. even for simple project with two
> modules dub is not able to do incremental rebuilds:
>
> === source/app.d ===
> import std.stdio;
> import mymod;
>
> void main () {
>    writeln(test);
> }
>
> === source/mymod.d ===
> module mymod;
>
> int test () { return 42; }
>
> % dub --build-mode=singleFile
> Building _00 ~master configuration "application", build type debug.
> Compiling using dmd...
> Compiling source/app.d...
> Compiling source/mymod.d...
> Linking...
> Running ./_00
> 42
>
> so far, so good.
>
> touch source/app.d
> % dub --build-mode=singleFile
> Building _00 ~master configuration "application", build type debug.
> Compiling using dmd...
> Compiling source/app.d...
> Compiling source/mymod.d...
> Linking...
> Running ./_00
> 42
>
> ??? i didn't modified "mymod.d"! why it is rebuilding it?! 'cmon, it's in
> no way better than a simple shell script that just executes "dmd -c" for
> each file and then links the results.
>

Yes, incremental building is indeed a missing feature. It's simply a matter of available developer time, as for many of the other concerns. Otherwise this is something that has been acknowledged for inclusion basically since the beginning of the project.

On Thursday, 5 February 2015 at 15:01:57 UTC, Sönke Ludwig wrote:
> Am 02.02.2015 um 09:09 schrieb Vladimir Panteleev:
>> On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy wrote:
>> 1. rdmd
>>
>
> BTW, there is one thing about RDMD that can be a real issue and one that is not easily solved without integrating its functionality directly into DMD: It doesn't track local and string imports. This is the main reason why I haven't personally used it since a while, although it is directly supported with "dub --rdmd".

String imports: just checked. It does. It uses dmd to get the imports so I thought it'd be weird if it didn't.

What's a local import? You mean this?

void func() {
    import mymodule;
}

Because I just tried that and it worked, too.

Atila

Am 05.02.2015 um 15:56 schrieb ketmar:
> On Thu, 05 Feb 2015 15:51:23 +0100, Sönke Ludwig wrote:
>
>> Am 02.02.2015 um 15:59 schrieb ketmar:
>>> On Mon, 02 Feb 2015 14:18:47 +0000, Tobias Pankrath wrote:
>>>
>>>> At least I don't expect Dub to support every single language out there
>>>> natively.
>>>
>>> that's why other build tools allows to manually specify dependencies
>>> and commands as a last resort. but dub can't.
>>>
>>>
>> Such as "preBuildCommands" [1]?
>>
>> [1]: http://code.dlang.org/package-format#build-settings
>
> nope. such as "'a' depends of 'b', 'b' depends of c, here are commands to
> generate 'a' and 'b', don't call that commands if it's not necessary".
> "...always before the project is built" is not what i excepting from
> decent build tool.
>

Okay, so '"preBuildCommands": ["cd something && make"]' (or some other generic build tool instead of make)

The approach taken for DUB is to put as much knowledge of the target problem into the build tool as possible, so that the amount of work/knowledge required by the developer is minimal (as long as problem is within the target domain). Make's approach is the opposite and requires the developer to spell out every detail of the build process for each project. Both approaches have their advantages and DUB provides the command functionality specifically to enable bridging this gap.

Apart from that, directly supporting C/C++ builds is something that should be implemented, too, but that requires a lot of additional work.