On 2 February 2015 at 21:04, Tobias Pankrath via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 2 February 2015 at 11:00:20 UTC, Manu wrote:
>>
>> 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 don't understand, can't you just use a C build tool for the C lib and link to it via dub?

If I have another build tool, then I already have a build tool. Why would I want 2 build tools? Double the trouble.

On Monday, 2 February 2015 at 14:17:26 UTC, Manu wrote:
> On 2 February 2015 at 21:04, Tobias Pankrath via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Monday, 2 February 2015 at 11:00:20 UTC, Manu wrote:
>>>
>>> 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 don't understand, can't you just use a C build tool for the C lib and link
>> to it via dub?
>
> If I have another build tool, then I already have a build tool. Why
> would I want 2 build tools? Double the trouble.

At least I don't expect Dub to support every single language out there natively.

On Monday, 2 February 2015 at 14:18:48 UTC, Tobias Pankrath wrote:
>> If I have another build tool, then I already have a build tool. Why
>> would I want 2 build tools? Double the trouble.
>
> At least I don't expect Dub to support every single language out there natively.

> If my D project depends on a C lib, then what am I supposed to do to
> make dub useful for me?

And deliberately mixing two programming languages in one project is another and (far more niche) problem than "depending on a c-lib". Many of my projects depend on a C lib and it works.

On 3 February 2015 at 00:18, Tobias Pankrath via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 2 February 2015 at 14:17:26 UTC, Manu wrote:
>>
>> On 2 February 2015 at 21:04, Tobias Pankrath via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On Monday, 2 February 2015 at 11:00:20 UTC, Manu wrote:
>>>>
>>>>
>>>> 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 don't understand, can't you just use a C build tool for the C lib and
>>> link
>>> to it via dub?
>>
>>
>> If I have another build tool, then I already have a build tool. Why would I want 2 build tools? Double the trouble.
>
>
> At least I don't expect Dub to support every single language out there natively.

Right. Therefore, dub is no use to me.
There are other great cross-language build tools that support D, and
more target environments than dub, which I use instead.

On Monday, 2 February 2015 at 14:11:12 UTC, Mathias LANG wrote:
> You can do that using configuration sections:
> http://code.dlang.org/package-format#configurations

I addressed this in my original post.

> I don't see how this is a feature. I want all my file parsed and put inside the archive.

Use Dub, then. You asked if it can be done with rdmd.

> It works when you're in source. No difference.

No. It doesn't work if your project has dependencies. Which was my point entirely.

We are going in circles. I don't think there's much more to be said.

On Monday, 2 February 2015 at 14:25:35 UTC, Vladimir Panteleev wrote:
> On Monday, 2 February 2015 at 14:11:12 UTC, Mathias LANG wrote:
>> You can do that using configuration sections:
>> http://code.dlang.org/package-format#configurations
>
> I addressed this in my original post.
>
>> I don't see how this is a feature. I want all my file parsed and put inside the archive.
>
> Use Dub, then. You asked if it can be done with rdmd.
>
>> It works when you're in source. No difference.
>
> No. It doesn't work if your project has dependencies. Which was my point entirely.
>
> We are going in circles. I don't think there's much more to be said.

a little script that calls `dub describe`, extracts the import paths and then calls dmd -o- appropriately would be easy to do. There's no fundamental blocker here.

On Monday, 2 February 2015 at 09:44:18 UTC, Andrej Mitrovic wrote:
> Also:
>
> - Dub installs everything in ~/ (home, which on Windows is an awful location anywho). It's a pain in the ass for browsing dependencies in your editor. If it's just a submodule you can easily view it in the source tree (e.g. just open ./submodules/).

I admit it's a pain. I use Mono-D, which takes care of that, so I'm not running into that problem.

> Having it as a submodule also helps if you want to quickly try to edit a dependency in order to see if it fixes an issue. And if the fix is right you can even make a commit inside the submodule and push it to your fork of the dependency.
>
> With all the aliases or zsh-tricks this can be as easy as a few key presses.

It's a question of workflow. I use path dependency to my fork when I have to patch a library in order to get my project working. Then I P.R. and when everything's upstream, I fix the dependencies. It's more involved, but led me to patch Vibe.d a few time / report issues, so overall it's a win.

> - By default dub emits internal stack traces. This is an insane amount of visual noise that I don't want to read.
>

Absolutely right, and it has to be patched. Fun fact: I misstyped Vladimir's command in a hurry, and typed "rdmd -o- file.d" (instead of dmd). Gotta love the stacktrace.

> - If I want to try a new version of a dependency, I have to change the damn .json package file instead of doing a simple 'git checkout ...'. What's worse, I have to wait 15-20 minutes for the latest tagged version of a dependency to finally show up on code.dlang.org.
>
> I could use add-local, but it's broken[1].

I was not aware of that problem. Have you tried path dependencies ?

> - Shit breaks every N releases (where N is arbitrary). As if it's not enough that code tends to break between compiler releases, so do packages between DUB releases. Something that used to build half a year ago no longer does.
>
> I don't recall when was the last time an RDMD or Make update has ever broken my projects.
>
> - I'm not a fan of poorly tested software, and DUB falls into that category.


In general, things tend to break with every compiler release. What we need IMO (I mentionned it in the 2015H1 thread) is a CI system that build every package with a list of supported compiler and tag them accordingly.

> The bottom line is, time spent on dealing with package management bugs is completely wasted developer time.

I couldn't disagree more, but I understand how frustrating dub can be. I also had to adapt my workflow to it.

Quick summary of my opinion can look like this:

1) dub is a horrible build tool
2) git submodules is a horrible way for dependency management

First thing is something we can improve on in future and, actually, dub supports using rdmd as a build tool already.

Second thing is an inherent issue that won't change without some fundamental breaking changes in how hit submodules are implemented.

Because of that I am trying to push dub despite the fact I don't like lot of things about it personally.

----------------------------------------

Explaining why dub is a horrible build tool is hardly necessary - there are plenty of cases in this thread already.

So why git submodules don't really work?

1) Lack of version management

submodule remembers specific commit hash and that is all. As of recent git version one can also remember remote tracking branch (but it will still keep specific hash in history!)

This may not seem an issue if you have only few dependencies and control them all. But it scales badly once bulding the project needs many incompatible versions of the same dependency and dependency count increases in general.

2) Lack of local cache

This is really annoying when working with many project with similar dependencies - those will get cloned over and over again, taking quite some time. Can possibly be fixed with clever scripts that replace remotes with local repo paths but that is not out-of-the box solution

3) Lack of package repository

Biggest thing about dub is not dub tool itself. It is code.dlang.org and what it can become in future. Providing simple centralized way to discover new libraries and quickly try those in uniform matter is the way you build decentralized ecosystem (ironically).

With git submodules you are pretty much stick with doing GitHub search over and over again

4) Inherently coupled with specific DVCS

git and GitHub are most common (and officially endorsed) ways of version control in D world but those are not the only one. dub registry allows to use GitHub, GitBucket and source tarball packages in the same project - in simple uniform matter. It is a 100% in-house tool that does no depend on decisions of external project maintainers that provides a common API for everything else to interoperate

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.

On Monday, 2 February 2015 at 14:09:55 UTC, Vladimir Panteleev wrote:
> On Monday, 2 February 2015 at 14:06:46 UTC, John Colvin wrote:
>> You can do this with dub. You selectively include or exclude files/directories on a per-configuration basis.
>
> I have addressed this in my initial post.

Not really. You say that it amounts to doing the computers work for it. I don't understand how the computer is supposed to know, in the general case, which files are relevant for which configurations. You have to tell it somehow. Dub has various features that can be leveraged to achieve this goal.

>> Overall - while you do have some valid complaints - you don't seems to know dub particularly well. Maybe you do, but it's not coming across.
>
> I don't understand what point you're trying to say here. The thread starts with the line:
>
>>> I don't use Dub
>
> Andrej and I seem to have a very similar workflow, as the additional experience he shared would affect me as well if I tried to switch to it.

It seems there are 4 genuine problems that have been mentioned:

1) Dependency versioning at the git commit level.
2) Placing dependencies out-of-tree.
3) Cross-language builds.
4) Bugs.

Solutions:
1) Support for this could be added to dub. Alternatively dub packages could be based on a recursive clone, so if you really need submodules then you get them, but your package still works with dub.

2) --cache    I don't use it, but it seems like it would do what you want. Out-of-tree does have advantages though. Auto-created local symlinks to the global package cache would probably be best-of-both-worlds.

3) Genuinely difficult. Probably outside of the scope of dub.

4) The situations is better than it used to be. Note that dub is still pre-1.0