Am 02.02.2015 um 16:34 schrieb Vladimir Panteleev:
> On Monday, 2 February 2015 at 14:35:03 UTC, John Colvin wrote:
>> 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.
>
> As long as the source code is open, there is no fundamental blocker at
> all - only a scalar of required effort, and the resulting gain per
> effort expended. But in my case, nothing is blocked - it is not a
> question of "I want to use dub but can't", but "I can't use dub and
> don't really need to".

BTW, for what it's worth, you can also do this:
"DFLAGS=-o- dub build"

It will recognize the -o- and automatically skip the linker stage, too. But of course that doesn't make it automatically track dependencies.

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.

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

The problem is certainly not with the addition of dub.json, but with the change in directory layout.

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

Ah, good idea.

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

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

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

Atila

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.

Local imports:

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

On Thursday, 5 February 2015 at 15:01:48 UTC, ketmar wrote:
>
> ??? 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.

Looks like you missing one of my mails:
http://forum.dlang.org/post/knfueyhpseoviumkewzk@forum.dlang.org

On Thursday, 5 February 2015 at 15:14:53 UTC, Sönke Ludwig wrote:
> BTW, for what it's worth, you can also do this:
> "DFLAGS=-o- dub build"
>
> It will recognize the -o- and automatically skip the linker stage, too. But of course that doesn't make it automatically track dependencies.

Nice! Then all it needs is a parameter for the file to check.

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.

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

Atila

On Thursday, 5 February 2015 at 15:15:10 UTC, 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.
>
> Atila

I really hope more people will get on board with with the development of dub, instead of everyone rolling it's own solution.
The contributor graph, while non-informative in most project, shows a tendency:
https://github.com/D-Programming-Language/dub/graphs/contributors

On Thu, 05 Feb 2015 15:17:44 +0000, Mathias LANG wrote:

> On Thursday, 5 February 2015 at 15:01:48 UTC, ketmar wrote:
>>
>> ??? 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.
> 
> Looks like you missing one of my mails: http://forum.dlang.org/post/knfueyhpseoviumkewzk@forum.dlang.org

yes, i did. yet this is not the only thing dub cannot do. dub is not a build system, dub is a package manager and quickhacked batch builder in one application. and this is the root of all problems: they should be two completely separate things.