Am Fri, 5 Apr 2013 16:02:22 +0200
schrieb Andrej Mitrovic <andrej.mitrovich@gmail.com>:

> On 4/5/13, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
> > Another option is wildcards (std.*).
> 
> Yep, I use this for unittesting and it works nice.
> 
> On 4/5/13, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
> > -r should be disabled for such cases - thus, enabled only when there's one .d file and no .obj / .lib files.
> 
> The .lib file could be an import library.
> 
> On 4/5/13, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
> > I think we should promote the use of pragma(lib) instead.
> 
> I remember other compiler writers saying pragma should not be used (I
> think GDC was it).

It's not like we don't want to support it, we can't(*) implement
pragma lib in gdc due to gcc's architecture. (split into compiler (cc1d)
and link driver(gdc). cc1d can't communicate with gdc)

* With some effort (read hacks) it could be possible but it would likely
  prevent gdc from being merged into upstream gcc, so...

On Friday, 5 April 2013 at 14:01:31 UTC, Jacob Carlborg wrote:
> On 2013-04-05 15:45, Vladimir Panteleev wrote:
>
>> -r should be disabled for such cases - thus, enabled only when there's
>> one .d file and no .obj / .lib files. Although specifying library files
>> on the compiler's command line is a valid use case, compatible with
>> recursive compilation, I think we should promote the use of pragma(lib)
>> instead.
>
> Why not when there's multiple source files?

1) It will break tools like rdmd, for cases when the tool knows the exact set of modules that needs to be compiled
2) When would that be useful?

On Friday, 5 April 2013 at 14:02:36 UTC, Andrej Mitrovic wrote:
> I remember other compiler writers saying pragma should not be used (I
> think GDC was it).

I see, I didn't realize pragma(lib) wasn't implemented in GDC.

> Anyway, It's easier to reason about a feature if you only had to pass
> a single switch to enable the feature rather than having to remember
> some odd set of rules.

Certainly; but at the same time, I think this is an opportunity to make the tool do the right thing with the least keystrokes.

On 4/6/13, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
> Certainly; but at the same time, I think this is an opportunity to make the tool do the right thing with the least keystrokes.

Hmm yeah.

Well we should definitely give implementing it a try and see what the build times are like.

On 2013-04-06 04:05, Vladimir Panteleev wrote:

> 1) It will break tools like rdmd, for cases when the tool knows the
> exact set of modules that needs to be compiled
> 2) When would that be useful?

When building libraries of course.

-- 
/Jacob Carlborg

On Saturday, 6 April 2013 at 10:56:19 UTC, Jacob Carlborg wrote:
> On 2013-04-06 04:05, Vladimir Panteleev wrote:
>
>> 1) It will break tools like rdmd, for cases when the tool knows the
>> exact set of modules that needs to be compiled
>> 2) When would that be useful?
>
> When building libraries of course.

Why would you want recursive compilation plus specifying multiple modules?

For a library, you generally know the exact set of modules to be built. If not in a makefile / build script, you could write one dummy module that imports all of the library's components, and use that as the root of incremental compilation.

On 2013-04-06 13:02, Vladimir Panteleev wrote:

> Why would you want recursive compilation plus specifying multiple modules?

If you're building a library which as a dependency on another library, which you build from source. Perhaps not that common.

> For a library, you generally know the exact set of modules to be built.
> If not in a makefile / build script, you could write one dummy module
> that imports all of the library's components, and use that as the root
> of incremental compilation.

Using a dummy module is ugly.

-- 
/Jacob Carlborg

On 4/6/13, Jacob Carlborg <doob@me.com> wrote:
>> For a library, you generally know the exact set of modules to be built. If not in a makefile / build script, you could write one dummy module that imports all of the library's components, and use that as the root of incremental compilation.
>
> Using a dummy module is ugly.

It doesn't necessarily have to be dummy. I like to use an 'all.d' module which imports all of my library modules. I've used this technique to run unittest via "rdmd --main mylib\all.d". But being able to recursively compile a static library would be pretty nice.

On 4/5/13, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
> I noticed that compiling D programs in the usual manner (rdmd) is as much as 40% slower than it can be.

I've implemented the -rb and -rx switchex (the -r switch itself is taken, it's an undocumented switch). These switches are used to enable recursive builds and to exclude modules/packages, respectively[1]. The -rx switch can take a module name or a wildcard option, e.g. -rxfoo.* to exclude all modules from the package "foo".

I'm seeing about 30% faster clean builds when using DMD with this feature compared to using RDMD. But I've only tested this on smaller projects, I wonder what the impact is on larger projects.

The std and core packages, and the object module are implicitly excluded from building.

[1] : https://github.com/AndrejMitrovic/dmd/tree/BuildRecurse

Andrej Mitrovic:

> But I've only tested this on smaller
> projects, I wonder what the impact is on larger projects.

I think the recursive scan is mostly meant for small projects. I think large projects will usually use some kind of build scripts.

Bye,
bearophile