On 4/5/13, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
> I think -r is redundant, and should be the default action if only one module is given on DMD's command line. I can't think of plausible situations where this could be a problem.

$ dmd main.d foo.obj

If main has imports to 'foo', how will DMD know whether or not to compile foo.d or just link with foo.obj?

You could pass -rxfoo, but you'd still be breaking all existing build scripts which rely on non-recursive building.

> Considering that you can't have a module with the same name as a package, the same syntax for excluding both can be used, e.g. "-rxcrc32 -rxstd".

I guess it could work. But I'm hoping one day we'll be able to lift that restriction, it's quite a pain in the ass when porting C++ code that uses namespaces to D. So for future-compatibility I thought separating module and package switches might be nice. It's not a big deal though.

On Friday, 5 April 2013 at 11:29:20 UTC, Andrej Mitrovic wrote:
> On 4/5/13, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
>> I think -r is redundant, and should be the default action if only
>> one module is given on DMD's command line. I can't think of
>> plausible situations where this could be a problem.
>
> $ dmd main.d foo.obj
>
> If main has imports to 'foo', how will DMD know whether or not to
> compile foo.d or just link with foo.obj?
>

By checking if foo.obj is outdated in regards to foo.d

Turbo Pascal was doing this, so it shouldn't be too hard.

On the other hand it was using a modern linker, not one with UNIX compatible semantics.

--
Paulo

On 4/5/13, Paulo Pinto <pjmlp@progtools.org> wrote:
> By checking if foo.obj is outdated in regards to foo.d

The compiler doesn't know that foo.d was built into foo.obj, it has no way of knowing that.

On Friday, 5 April 2013 at 11:29:20 UTC, Andrej Mitrovic wrote:
> On 4/5/13, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
>> I think -r is redundant, and should be the default action if only
>> one module is given on DMD's command line. I can't think of
>> plausible situations where this could be a problem.
>
> $ dmd main.d foo.obj
>
> If main has imports to 'foo', how will DMD know whether or not to
> compile foo.d or just link with foo.obj?

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

> You could pass -rxfoo, but you'd still be breaking all existing build
> scripts which rely on non-recursive building.

Yes, the goal is to not affect existing scripts.

>> Considering that you can't have a module with the same name as a
>> package, the same syntax for excluding both can be used, e.g.
>> "-rxcrc32 -rxstd".
>
> I guess it could work. But I'm hoping one day we'll be able to lift
> that restriction, it's quite a pain in the ass when porting C++ code
> that uses namespaces to D. So for future-compatibility I thought
> separating module and package switches might be nice. It's not a big
> deal though.

Another option is wildcards (std.*).

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?

-- 
/Jacob Carlborg

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

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.

On Friday, 5 April 2013 at 12:51:58 UTC, Andrej Mitrovic wrote:
> On 4/5/13, Paulo Pinto <pjmlp@progtools.org> wrote:
>> By checking if foo.obj is outdated in regards to foo.d
>
> The compiler doesn't know that foo.d was built into foo.obj, it has no
> way of knowing that.

Hence my remark of a modern linker.

05-Apr-2013 18:12, Paulo Pinto пишет:
> On Friday, 5 April 2013 at 12:51:58 UTC, Andrej Mitrovic wrote:
>> On 4/5/13, Paulo Pinto <pjmlp@progtools.org> wrote:
>>> By checking if foo.obj is outdated in regards to foo.d
>>
>> The compiler doesn't know that foo.d was built into foo.obj, it has no
>> way of knowing that.
>

Something as simple as adding an MD5 digest plus a mime-type of a source file as a "finger-print" in a separate section would have worked.

It wouldn't even need to change how object files work but would preserve 1:1 mapping of sources to obj. And we could have gone this way in D but since C objects produced by other compiler won't have this ability it would be quite limited (and conservative).

> Hence my remark of a modern linker.

Yup, UNIX is so UNIX.

-- 
Dmitry Olshansky

On Fri, 05 Apr 2013 15:45:15 +0200
"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.

No, including static libs while using recursive compilation is definitely a very real need.

On 4/5/13, Paulo Pinto <pjmlp@progtools.org> wrote:
> Hence my remark of a modern linker.

Yeah but we're looking for something that works now. A modern linker for D is a distant dream right now, unfortunately..