On 2 February 2015 at 22:15, Nick Sabalausky via Digitalmars-d
> 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.

Just because they exist does not mean they are being used.  (ie: gdmd has been split away and EOL for over a year now).

Am 05.02.2015 um 16:51 schrieb Atila Neves:
> 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

I think my personal favorite would be to directly improve the existing build system [1]. This would have the strongest impact, as everyone using DUB would directly profit. We'd still have to decide if/how the build functionality should be separated into another executable or shared library, but that wouldn't invalidate the existing work.

Directly creating a separate tool that invokes "dub describe" to get the required build information would of course have the advantage of explicitly separating building from package meta information gathering right from the start. But it has the disadvantage that it requires some more work up front to convert the JSON back into a more manageable runtime representation and we'd have to think about how this will all fit together in the long run (e.g. does the user invoke the build tool directly or does DUB do that? Or do we maybe implement some git-like plug-in functionality, so that "dub build" calls "dub-build" internally?)

[1]: https://github.com/D-Programming-Language/dub/blob/master/source/dub/generators/build.d

Am 05.02.2015 um 16:15 schrieb Vladimir Panteleev:
> On Thursday, 5 February 2015 at 14:48:24 UTC, Sönke Ludwig wrote:
>>> - restructure the directory layout of my library (breaking change)
>> Not true. Use "sourcePaths" and "importPaths" to configure the package
>> as appropriate.
>
> Right now this is necessary to maintain directory/package path consistency.

(Still reading the thread) If you mean that fetched packages are stored within "<packagename>-<packageversion>" folders, that's true of course, I didn't think of that. So it wouldn't work for a publicly registered package, but it would still work if you just use the library as a git submodule, or using some other kind of checkout protocol that keeps the original folder name. I think we should look into a fix here, such as using "<packagename>-<packageversion>/<packagename>".

>
>>> - 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.
>
> I think the only build script I had to write was for RABCDAsm, which
> probably can't be reimplemented as a dub.json file:
>
> http://forum.dlang.org/post/peurhbfebwdskcballzk@forum.dlang.org
>
> For DFeed and a few small projects I use Makefiles and packaging
> scripts, but they also do more complicated things such as signing
> Windows executables, compressing/compiling resources, and applying
> .manifest files.
>
> In general, I've tried to make things work with rdmd alone.

Okay, things like testing for DMD bugs and signing stuff would indeed still have to be done outside of DUB using a separate pre(Build/Generate)Command (a failing command should automatically stop the build), but at least the dependency management part (haveLZMA) should map fine to DUB packages.

I agree that if you only look at it in this context, that DUB may look like a useless complication (two build scripts/files instead of one). The real advantage comes when things like complex dependency trees or IDE project files get involved.

>
>>> - 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.
>
> I can see how that is more practical for public libraries. Commit
> granularity helps if you want reproducible builds, though.

Fun fact: If you register a GIT working copy using "dub add-path/add-local" and it doesn't have an exact tag checked out, then any package that uses it, will have something like this in its dub.selections.json file: '"vibe-d": "0.7.22+commit.17.g75ecb6b"', where "0.7.22" is the latest version tag on that branch and the suffix is the current commit hash.

This information is currently not used to drive GIT and automatically check out that same commit before building. But we could of course implement that in one form or another to have fully reproducible builds with commit granularity.

On 2/5/15 7:15 AM, Atila Neves wrote:
>> 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.
>
> The approach is a good one. There's just a lack of flexibility. I know
> it's a lot of work, I'm definitely willing to making it happen.

That's fantastic. -- Andrei

Am 05.02.2015 um 16:16 schrieb Vladimir Panteleev:
> On Thursday, 5 February 2015 at 15:01:57 UTC, Sönke Ludwig wrote:
>> 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 were fixed recently, I think.

Good to know. This would make it practical to use for me again.

>
> Local imports:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=7016
>

Am 05.02.2015 um 16:12 schrieb Atila Neves:
> 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

Exactly, see also Vladimir's ticket: http://d.puremagic.com/issues/show_bug.cgi?id=7016

It only seems to happen for imported modules and not for the one passed directly to DMD, AFAICS.

Am 02.02.2015 um 21:05 schrieb Dragos Carp:
> On Monday, 2 February 2015 at 16:26:45 UTC, Atila Neves wrote:
>> This thread has just made me decide to write a D build system, in D
>> and configured in D that builds on dub and its packages intead of
>> reinventing the wheel. I might ask the community for inputs on
>> requirements. Maybe this will be my DConf 2015 submission.
>
> Why not building on cmake? You have experience with it. trentforkert
> made very good progress with D support in cmake and has good chances to
> merge it upstream [1].
>
> If we look at the Vision/2015H1 goals, we see a couple of points, where
> cmake already has the necessary support:
>
> - C++ integration (hybrid projects)
> - alternative compilers
> - embedded systems
>
> This features would take a lot of effort/time to be implemented in a
> pure D solution, nevertheless any of these points is a niche in the D
> community.
>
> Apart from the ugly script language, cmake would be a pretty good fit.
>
>
> [1] - https://github.com/trentforkert/cmake

BTW, CMake output support (using "dub generate cmake") has recently been added to GIT master.

Am 03.02.2015 um 19:07 schrieb Russel Winder via Digitalmars-d:
> On Tue, 2015-02-03 at 13:19 +0000, Tofu Ninja via Digitalmars-d wrote:
> […]
>> Why not invest your time into improving dub and adding these
>> features, we don't need another tool. Improving dub would have a
>> much bigger impact than making another tool that is almost
>> certainly never going to get used because very few tools ever get
>> to that level.
>
> Because they feel that Dub is fundamentally flawed as the future
> solution to D (C++/C) build?
>>
>> Honestly it seems like a huge waist of time and very counter
>> productive.
>
> I disagree. This sort of argument was made before Dub and yet Dub
> happened.
>
> If people want to improve on Dub and replace it by doing exactly that,
> that seems like the best way forward.
>
> I have just realized why I think Dub will not be the future of D build…
>

Thanks for that kick in the teeth. I'm now just left wondering what it is that is "fundamentally flawed". Everything mentioned so far is either bugs or missing functionality, or rather just mostly missing convenience.

Things may not (yet) be ideal, but fundamentally DUB is nothing more than a tool built on a defined abstract package description format (vs. a procedural build description). If you (or anyone else for that matter) want to say that using a descriptive format is fundamentally flawed then I'd be grateful for some additional substantiation. Otherwise there is nothing "fundamental" in the system that I know of.

Am 05.02.2015 um 16:35 schrieb ketmar:
> 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.

If you just want to have a build tool, that's fine (if you want to do all the dependency tracking and cross platform/compiler compatibility stuff by hand). But the main point is that you can seamlessly use foreign packages, which is not really possible with make (well, of course it is...).

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

It will gain C/C++ build support, so that particular issue should at that point be a thing of the past. The "preBuildCommands" feature *is* a way to make hard things possible. It may not hit the sweet spot in your particular case, because it requires another tool to achieve the job, but it's definitely doable.

The development approach has been to try to get those features in first that enable the most common use cases. Certain things will always require the use of external tools/scripts (maybe some kind of embedded scripting functionality as an alternative to the command feature would also be an option), but it should be no problem to push the boundary of what's possible within the package description format to a level where >99% of people can be happy.

>
> BTW, CMake output support (using "dub generate cmake") has recently been added to GIT master.

Very nice!