Am Mon, 06 Apr 2015 10:21:45 +0200
schrieb Sönke Ludwig <slud...@rejectedsoftware.com>:

> The new version contains some important bug fixes for sub modules and 
> overridden string imports, as well as some other major fixes. Apart from 
> that, the major additions are:
> 
>   - "copyFiles" now get hard linked instead of copied and whole
>     directories can be copied in addition to individual files
>   - The "dub init" command has been extended to take an optional list of
>     dependencies that is added to the generated dub.json
>   - A new "deimos" template has been been implemented
>     (dub init --type=deimos)
>   - The default compiler is now chosen based on what is found in PATH

How does it resolve preferences when 3 comilers are on PATH ? =)
dmd first?

>   - New project generators for Sublime Text and CMake
>   - In single file build mode, "--parallel" can now be used to compile
>     with multiple compiler instances at once
> 
> Find the full list of changes in the change log [1] and download at:
> 
> http://code.dlang.org/download
> 
> [1]: https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

And one idea that recently came to my mind since I'm a fan of
shared libraries. Would it work in D to say compile a shared
library and generate a number of .di files required to use it?
Similar to druntime that provides only a hand full of its
modules as .di or where necessary as .d files.

I'm looking for a perspective out of the "compile the world"
model in Dlang, since as far as I understand it, the D
front-end will always parse all imported modules recursively.
Even in single-file compilation mode, when only "app.d"
changed it would parse the whole thing down to the last corner
of all used D libraries like GtkD or vibe.d.

With the minimum amount of required .di files for libraries,
further private imports inside their modules are hidden away
from the compiler, thereby short-circuiting the "import the
world" recursion.

-- 
Marco

Reply via email to