On Thu, 05 Feb 2015 15:21:08 +0000, Atila Neves wrote:

>> the package manager part should have good "machine" interface to allow it's usage in various scripts and other build systems. and build system... oh, well, it can simply use package manager. this way we can discuss "dub-pkg" and "dub-build" as separate entities, and flaws of one project will not automatically propagate on another project.
> 
> The machine interface is "dub describe". It's JSON, so... that's what my Emacs package uses to pass -I flags to dmd for on-the-fly syntax checks.

there is too much noise there. and there is no easy access to package manager itself. as far as i can see, there is no command even to list all *known* packages, only installed ones.

On Thursday, 5 February 2015 at 15:26:23 UTC, ketmar wrote:
> On Thu, 05 Feb 2015 15:21:08 +0000, Atila Neves wrote:
>
>>> the package manager part should have good "machine" interface to allow
>>> it's usage in various scripts and other build systems. and build
>>> system... oh, well, it can simply use package manager. this way we can
>>> discuss "dub-pkg" and "dub-build" as separate entities, and flaws of
>>> one project will not automatically propagate on another project.
>> 
>> The machine interface is "dub describe". It's JSON, so... that's what my
>> Emacs package uses to pass -I flags to dmd for on-the-fly syntax checks.
>
> there is too much noise there. and there is no easy access to package
> manager itself. as far as i can see, there is no command even to list all
> *known* packages, only installed ones.

Define noise in a M2M context.
Accessing to all known packages wouldn't be hard to implement (hint: https://github.com/D-Programming-Language/dub/commit/5a93ab440017aa0998c50edda5cabad7c2bffc5f), it just need a dev^W champion.

> there is too much noise there. and there is no easy access to package
> manager itself. as far as i can see, there is no command even to list all
> *known* packages, only installed ones.

You don't need to know all packages, only the ones required by the build and where they are. For a build system, anyway, there's obviously value in listing all known packages. Adding arbitrary dependencies and tasks to the package dependencies is what completes the picture.

Atila

On Thu, 05 Feb 2015 16:12:51 +0100, Sönke Ludwig wrote:

>>> 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)

so i'll use "make" for everything else too. "make" can be wordy, but at least i'll have only one build tool to care about, not two.

there is nothing wrong in making easy things easy ;-), but dub has no way to make hard things possible. i can't teach it new tricks, and i definitely don't want "build systems explosion" in my projects. and dub can't be easily used like "pkg-config", so even it's package management part is not good for non-dub people.

Am 02.02.2015 um 23:15 schrieb Nick Sabalausky:
> On 02/02/2015 03:09 AM, Vladimir Panteleev wrote:
>> 1a. rdmd and D's module system:
>> [...]
>> In contrast, Dub's default modus operandi is to blindly send to the
>> compiler all *.d files found in the "src" folder, whether they're
>> actually used or not. Not only can this be slower if not all modules are
>> always used, but it also won't work if the source code contains multiple
>> entry points, forcing you to write complicated configuration files (i.e.
>> do the computer's work for it).
>>
>
> This is one of my biggest beefs with dub, too, and constantly causes me
> trouble. (I love that dub exists as a package manager, but I REALLY
> dislike that it tries to be build system too. Especially since I don't
> like the way its build functionality works.)

Short answer: This is required to properly support other build systems/IDEs.

>
> In theory, dub does have the --rdmd switch to make it select source
> files in a sane manner (by deferring to rdmd), but unfortunately it
> doesn't get well-tested and frequently breaks:
>
> https://github.com/D-Programming-Language/dub/issues/492

Briefly looking at it, I'm pretty sure that this is actually a DMD/RDMD issue. The import statements for the internal event driver recently have been made function local to speed up compilation. And if nothing has changed, DMD simply doesn't output function local dependencies with -o-, so that RDMD fails to include the proper modules.

>
>> 1b. rdmd and D's search path
>>
>> rdmd does not have any additional parameters to set up for where it
>> needs to look for source files, because it relies on the compiler's
>> search mechanism. Thus, if you can build your program with rdmd, "dmd
>> -o- program" will succeed, and usually vice versa.
>>
>> In contrast, Dub builds its own search path using its JSON configuration
>> files, and has no equivalent of "dmd -o-".
>>
>> There is no simple way to syntax-check just one file in a project when
>> using Dub. I rely on this a lot in my workflow - I configured a
>> syntax-check key in my editor, which I use almost as often as I save. A
>> syntax check (dmd -o-) is much faster than a full build, as it skips
>> parsing other parts of the project, code generation, and linking.
>>
>
> My #1 beef with Dub: It desperately needs a way to *just* obtain the
> -o/-version/etc args to be passed directly into dmd/rdmd/ldmd/gdmd/etc.
> Without that, dub is useless as a MERE package manager. It's either
> packaging AND building, or nothing. (Ever try to use a recent version of
> vibe.d in a project that *doesn't* use dub as its build system? PITA. It
> isn't even recommended to do so.)

There is "dub describe" for this. There is also a pending feature to support the use of shell variables instead of piping everything to stdout.

>
> I tried to add that feature one time, but I had trouble grokking the
> relevant section of dub's source :(
>
> There's also one other big thing I don't like about it: It needlessly
> reinvents and renames dmd's entire set of command switches. That isn't
> even needed for ldc/gdc anyway since, last I heard, the ldmd and gdmd
> wrappers exist. I pushed to get the *actual* compiler switched accepted
> by dub, and the feature made it in, but trying to use it generates a big
> giant warning for all your library's users complaining that the feature
> *shouldn't* be used. Thus completely defeating the point. Argh.

The question is how tight everything should be bound to DMD. For example, does SDC have an sdmd wrapper? The goal was to make the package description independent of the compiler used to build it (at least in most cases). An alternative way to using an own way to describe build options would of course have been to always rely on DMD's option format and translate as required (which is supported, as you already mentioned). But that will in turn feel strange to anyone not using DMD.

>
> Again, I love that Dub (and especially it's package repository) exists.
> But dub just tries to hard to impose it's own way.
>

On Thu, 05 Feb 2015 15:34:06 +0000, Atila Neves wrote:

>> there is too much noise there. and there is no easy access to package manager itself. as far as i can see, there is no command even to list all *known* packages, only installed ones.
> 
> You don't need to know all packages, only the ones required by the build and where they are.

i don't need that, but my "configure" script may need to. ah, isn't list of all *available* packages is a part of the core functionality of package system? ;-)

On Thu, 05 Feb 2015 15:33:51 +0000, Mathias LANG wrote:

> On Thursday, 5 February 2015 at 15:26:23 UTC, ketmar wrote:
>> On Thu, 05 Feb 2015 15:21:08 +0000, Atila Neves wrote:
>>
>>>> the package manager part should have good "machine" interface to allow it's usage in various scripts and other build systems. and build system... oh, well, it can simply use package manager. this way we can discuss "dub-pkg" and "dub-build" as separate entities, and flaws of one project will not automatically propagate on another project.
>>> 
>>> The machine interface is "dub describe". It's JSON, so... that's what my Emacs package uses to pass -I flags to dmd for on-the-fly syntax checks.
>>
>> there is too much noise there. and there is no easy access to package manager itself. as far as i can see, there is no command even to list all *known* packages, only installed ones.
> 
> Define noise in a M2M context.

i don't give a shit about all that 60 lines of crap "dub describe" spits. i'm only interested in "dependencies" parts and... oh, and in compiler flags and pathes, which aren't even there. everything else is just a noise.

> Accessing to all known packages wouldn't be hard to implement (hint: https://github.com/D-Programming-Language/dub/
commit/5a93ab440017aa0998c50edda5cabad7c2bffc5f),
> it just need a dev^W champion.

there is no sense in implementing it in dub anyway. at least while dub insists to be a build system.

Am 03.02.2015 um 09:51 schrieb ketmar:
> On Tue, 03 Feb 2015 02:19:55 +0000, Martin Nowak wrote:
>
>> There seems to be a general scepticism against dub and I wonder what the
>> reasons are.
>
> 'cause it really sux as a build tool.
>

Just to state the design perspective for a little bit of rationale: DUB is not designed to be a build tool itself, but rather to operate on a meta level, able to invoke other build tools or to generate foreign build descriptions, similar to what CMake and similar systems do. This is the reason why its own build system is rather simple (i.e. hasn't received enough work to be more comprehensive) and doesn't yet support things like incremental builds (there are additional reasons for this, though). It's meant to provide a convenient default functionality, but doesn't claim to be fully featured.

On Thursday, 5 February 2015 at 15:46:57 UTC, Sönke Ludwig wrote:
> Am 03.02.2015 um 09:51 schrieb ketmar:
>> On Tue, 03 Feb 2015 02:19:55 +0000, Martin Nowak wrote:
>>
>>> There seems to be a general scepticism against dub and I wonder what the
>>> reasons are.
>>
>> 'cause it really sux as a build tool.
>>
>
> Just to state the design perspective for a little bit of rationale: DUB is not designed to be a build tool itself, but rather to operate on a meta level, able to invoke other build tools or to generate foreign build descriptions, similar to what CMake and similar systems do. This is the reason why its own build system is rather simple (i.e. hasn't received enough work to be more comprehensive) and doesn't yet support things like incremental builds (there are additional reasons for this, though). It's meant to provide a convenient default functionality, but doesn't claim to be fully featured.

Which is fair enough. I want to contribute and write a fully featured one, though. Either as a plugin, a self-contained tool that builds on dub or something else. How do you suggest I proceed, if at all?

Atila

Am 05.02.2015 um 16:18 schrieb ketmar:
> On Thu, 05 Feb 2015 16:05:11 +0100, Sönke Ludwig wrote:
>
>> 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.
>
> alas, without this feature dub is not a build system. i understand that
> there are alot of things to do and the resources are limited. that's why
> i think that dub should be separated to two projects: package manager and
> build system.
>
> the package manager part should have good "machine" interface to allow
> it's usage in various scripts and other build systems. and build
> system... oh, well, it can simply use package manager. this way we can
> discuss "dub-pkg" and "dub-build" as separate entities, and flaws of one
> project will not automatically propagate on another project.
>

That's how it is meant to be! Maybe separating the build functionality into a separate executable would indeed be a good idea to express this more clearly (even if it wouldn't change anything practically). But the main goals were to provide the "dub generate" and "dub describe" functionality, so that any build system could be used.

GIT master now supports generating VisualD, CMake and Sublime Text project files. "Make" is also a commonly requested one that would be easy to add, but hasn't been done yet. Of course it also supports RDMD using "dub build --rdmd".