Am 04.06.2015 um 15:07 schrieb Steven Schveighoffer:
> On 6/4/15 4:58 AM, Sönke Ludwig wrote:
>>
>> As of recently, you can also directly specify dependencies to the "dub
>> init" command, for example "dub init myproject tango derelict-gl".
>
> That's nice. But it still isn't self-explanatory. Nor additive.

A command to add/remove dependencies might be useful. But the question is where to stop. Does it make sense to have a command to edit the description? Or add compiler flags? Or manage configurations or sub packages? It also gets a little hairy w.r.t. keeping possible user formatting in the package description file, especially once support for comments gets added.

>
>> There
>> was also the suggestion to make dub init (without arguments)
>> interactive, which would make this a really easy matter.
>
> This would be better, but I still think a way to add dependencies should
> be supported on the command line. Something like dub depend someproject.
> You don't always know what a project will need at the beginning.
>
> Of course, you could just say "well, edit the json file!". You really
> need a format that supports comments...

Agreed, that is really needed. It's almost on top of the TODO list.

>
> In any case, this doesn't negate the concerns others have raised.
>
> I don't mean to bash dub, it's better than nothing. But I haven't used
> it for any real project yet. And when I did use it, it was not a
> straightforward experience.
>

The important part is to not stop with voicing criticism, but to actively help to improve the situation. Opening tickets or "voting" on existing ones, or even making an enhancement proposal or an actual PR would be the most constructive.

It's a little sad how some people seem to perceive DUB as being static and unable to evolve. That is not the case. It has started out with a small core functionality to get something that benefits a lot of people right away. But everything has been done in a way that allows to extend or generalize things later.

Not everyone will agree with its philosophy to provide high level declarative abstractions instead of a low level system that can be used to create abstractions within the build language, but I'm very positive that this approach is much more useful for the vast majority of users (and especially for newcomers). Retrofitting existing build approaches can of course sometimes come with friction, but even that should be solvable one way or another in most cases.

In any case, probably all of the mentioned criticism so far seems to be based on nothing more than missing functionality or bugs and nothing that would go against the existing design. An exception is support for other high level tasks, such as "deployment" targets or similar. This has never been the scope and I don't think we should go that way.

On a related note, it's also a pity that Reggae mixes incremental build improvements (from which DUB itself could greatly profit, too - just as a Ninja generator for DUB would be a nice feature) with a separate, layered build description. I mean there is of course no reason to not have alternative approaches for build descriptions available in general, but when mixed with a public package repository, it just leads to fragmentation.

Sorry for the slightly OT reply, most of this isn't targeted at you, I just went through the newsgroup posts for the first time after a while and needed to get this out.

On 06/04/2015 04:43 AM, Sönke Ludwig wrote:
> Am 01.06.2015 um 08:35 schrieb Nick Sabalausky:
>> On 05/31/2015 07:01 PM, Andrei Alexandrescu wrote:
>>> Let's make this part of 2.068:
>>>
>>> https://issues.dlang.org/show_bug.cgi?id=14636
>>>
>>> It's preapproved. Who would want to work on it?
>>>
>>
>> IIRC, I think Sonke wanted to hold off on that until a dub 1.0. I'm not
>> certain exactly what work he had in mind for that though, versus
>> post-1.0.
>>
>
> We have collected some things that would be good to have done. There are
> no big issues left, though,

Cool.

> except for making the API stable and
> supporting the improved build description language.

Is there anything you need from me on the latter? (If a particular matter quiets down or I get distracted, I'm liable to forget about it.)

Am 04.06.2015 um 17:03 schrieb Nick Sabalausky:
> On 06/04/2015 04:39 AM, Sönke Ludwig wrote:
>>
>> Of course you could make the system completely build
>> tool agnostic, but then you'd basically lose interoperability between
>> packages, as each package might choose its own build tool.
>>
>
> With this PR and the upcoming follow-up to add
> --format=(list|some_compiler|whatever), there is NO issue with package
> interoperability (as long as a package's "import-paths" is correct):
>
> https://github.com/D-Programming-Language/dub/pull/572

Just to get this straight: Supporting external build tools like that and by writing the proper generator has always been the goal of DUB (being build tool agnostic). The built-in builder is basically mainly there for convenience (although there is no reason not to improve it to the point where it is a worthy competitor). But you still use DUB's build description in that case.

What I really meant (and didn't really say) was if you completely remove all build description related fields from dub.json - then you lose interoperability.

>
> Note that even WITHOUT dub, packages from different buildsystems
> *already* interop just fine. Even in C-land. All you ever need for
> packages to work together is the appropriate "build this package"
> command and the import/lib paths for the compiler/linker. Buildsystem is
> a package-local issue, not a cross-package issue.
>

That's not what I had in mind with "interoperability". That would rather be gluing them together manually. Of course you can always do that, but then you lose a lot of potential for avoiding useless/redundant work. It means you are doing the job that the tool should (could) do.

This also gets especially interesting and annoying when compiler flags (e.g. version identifiers) don't match, or the dependencies require advanced compiler flags. I really think C/C++ is the last thing we should take as our role model when it comes to this topic (apart from C's strict ABI perhaps).

Am 04.06.2015 um 17:08 schrieb Nick Sabalausky:
> On 06/04/2015 04:43 AM, Sönke Ludwig wrote:
>(...)
>> except for making the API stable and
>> supporting the improved build description language.
>
> Is there anything you need from me on the latter? (If a particular
> matter quiets down or I get distracted, I'm liable to forget about it.)
>

I think Dicebot did some work recently (or intended to do?). It's actually not that much work overall. I could also pick up what's there and finalize things over the next days.

> On a related note, it's also a pity that Reggae mixes incremental build improvements (from which DUB itself could greatly profit, too - just as a Ninja generator for DUB would be a nice feature) with a separate, layered build description. I mean there is of course no reason to not have alternative approaches for build descriptions available in general, but when mixed with a public package repository, it just leads to fragmentation.

I can add a ninja generator to dub if you want, with the default being per-package compilation (since right now for dub it's one file or everything at once).

But I wrote reggae because:

1. Declarative is preferable but imperative is needed. My (our?) favourite imperative language is D, so I want to specify builds in it.
2. I want a build tool that builds on dub but doesn't require it
3. I wanted it to make it easy to link with C and C++

As I've mentioned before, I know the kind of things I'd want to do with the build system if I had a large and complicated enough project, and I know I wouldn't be able to do it easily using dub alone. As I've also mentioned before, building with dub is just fine for most people.

I don't know if fragmentation would be an issue. The packages are still dub packages and I for one will use dub.json/sdl to list my dependencies even if reggae is actually generating the build.

Atila

On 06/04/2015 11:33 AM, Sönke Ludwig wrote:
> Am 04.06.2015 um 17:03 schrieb Nick Sabalausky:
>> On 06/04/2015 04:39 AM, Sönke Ludwig wrote:
>>>
>>> Of course you could make the system completely build
>>> tool agnostic, but then you'd basically lose interoperability between
>>> packages, as each package might choose its own build tool.
>>>
>>
>> With this PR and the upcoming follow-up to add
>> --format=(list|some_compiler|whatever), there is NO issue with package
>> interoperability (as long as a package's "import-paths" is correct):
>>
>> https://github.com/D-Programming-Language/dub/pull/572
>
> Just to get this straight: Supporting external build tools like that and
> by writing the proper generator has always been the goal of DUB (being
> build tool agnostic). The built-in builder is basically mainly there for
> convenience (although there is no reason not to improve it to the point
> where it is a worthy competitor). But you still use DUB's build
> description in that case.
>
> What I really meant (and didn't really say) was if you completely remove
> all build description related fields from dub.json - then you lose
> interoperability.
>

Oh, right. I have no issue with dub *having* a built-in buildsystem. (And it is fine and convenient for a lot of things, even if not everything.) I've just hit roadblocks trying to use other buildsystems instead and am only just now getting around to addressing those issues.

On 6/4/15 11:07 AM, Sönke Ludwig wrote:
> Am 04.06.2015 um 15:07 schrieb Steven Schveighoffer:
>> On 6/4/15 4:58 AM, Sönke Ludwig wrote:
>>>
>>> As of recently, you can also directly specify dependencies to the "dub
>>> init" command, for example "dub init myproject tango derelict-gl".
>>
>> That's nice. But it still isn't self-explanatory. Nor additive.
>
> A command to add/remove dependencies might be useful. But the question
> is where to stop. Does it make sense to have a command to edit the
> description? Or add compiler flags? Or manage configurations or sub
> packages? It also gets a little hairy w.r.t. keeping possible user
> formatting in the package description file, especially once support for
> comments gets added.

Editing strings that don't affect the build doesn't seem like a necessary thing. An interactive init would probably solve that.

However, things like adding or removing a dependency would be very nice without having to know the format of the file. I'm trying to think of things that a simple first-time user would use dub for, aside from adding dependencies. Perhaps creating a debug build. Other than that, I think editing the file for nitty gritty details is probably OK.

The use case I'm thinking of is basically:

import somepackage.somemodule;
...

compile -> can't find somepackage.somemodule.
did you mean somepackage.somemodule from libgeneric on code.dlang.org?
   (url)
   to add: dub depend add libgeneric

dub depend add libgeneric => found it, added it, added dependency

I don't have to look up anything on code.dlang.org, I don't have to do anything, dub figures it all out from the description file online.

I think of things like linux shell on my linuxmint installation (ubuntu based), which uses some cool things:

user> blah
No command 'blah' found, did you mean:
 Command 'blam' from package 'blam' (universe)

>> Of course, you could just say "well, edit the json file!". You really
>> need a format that supports comments...
>
> Agreed, that is really needed. It's almost on top of the TODO list.

That is good!

>> In any case, this doesn't negate the concerns others have raised.
>>
>> I don't mean to bash dub, it's better than nothing. But I haven't used
>> it for any real project yet. And when I did use it, it was not a
>> straightforward experience.
>>
>
> The important part is to not stop with voicing criticism, but to
> actively help to improve the situation. Opening tickets or "voting" on
> existing ones, or even making an enhancement proposal or an actual PR
> would be the most constructive.

Not using dub frequently means I have a very sparse relationship with it. It's kind of that chicken and egg thing. I'm sure if I started having to use dub for a project, I would become more involved :)

> Sorry for the slightly OT reply, most of this isn't targeted at you, I
> just went through the newsgroup posts for the first time after a while
> and needed to get this out.

No problem, please keep up the dialogue!

-Steve

On Thursday, 4 June 2015 at 15:39:02 UTC, Sönke Ludwig wrote:
> Am 04.06.2015 um 17:08 schrieb Nick Sabalausky:
>> On 06/04/2015 04:43 AM, Sönke Ludwig wrote:
>>(...)
>>> except for making the API stable and
>>> supporting the improved build description language.
>>
>> Is there anything you need from me on the latter? (If a particular
>> matter quiets down or I get distracted, I'm liable to forget about it.)
>>
>
> I think Dicebot did some work recently (or intended to do?). It's actually not that much work overall. I could also pick up what's there and finalize things over the next days.

I got it to the point where I could build simple hello-world using dub.sdl description but haven't worked on it since then. This issue is neither interesting nor important to me, thus finding motivation is rather hard. Dump of last sources can be found here : https://github.com/Dicebot/dub/tree/sdl

Am 04.06.2015 um 19:55 schrieb Dicebot:
> I got it to the point where I could build simple hello-world using
> dub.sdl description but haven't worked on it since then. This issue is
> neither interesting nor important to me, thus finding motivation is
> rather hard. Dump of last sources can be found here :
> https://github.com/Dicebot/dub/tree/sdl

I'll pick it up from there in a few days.

On Thursday, 4 June 2015 at 15:07:58 UTC, Sönke Ludwig wrote:
> Am 04.06.2015 um 15:07 schrieb Steven Schveighoffer:
>> This would be better, but I still think a way to add dependencies should
>> be supported on the command line. Something like dub depend someproject.
>> You don't always know what a project will need at the beginning.

imho if a program consumes a particular configuration file, it should not also write it.
Counter examples: Visual Studio projects, MFC, IRC bouncers, and other technologies from Hell.


> On Thursday, 4 June 2015 at 15:07:58 UTC, Sönke Ludwig wrote:
> Sorry for the slightly OT reply, most of this isn't targeted at you, I just went through the newsgroup posts for the first time after a while and needed to get this out.

Be sure your work is appreciated, I couldn't imagine working without DUB everyday.

As always the NG isn't the masses but some vocal subset of D users.

Personally I won't use any library which is not on the DUB registry, learning how to build something is disposable knowledge.