Thread overview
Singleobj builds
Nov 01, 2016
Johan Engelen
Nov 01, 2016
kinke
Nov 01, 2016
kinke
Nov 07, 2016
Daniel9
Nov 07, 2016
Nordlöw
Nov 08, 2016
Johan Engelen
Nov 08, 2016
Nordlöw
Nov 08, 2016
Johan Engelen
November 01, 2016
Hi all,
  I just found this in mars.d:
```
  version (IN_LLVM)
  {
    if (global.params.oneobj && modules.dim < 2)
        global.params.oneobj = false;
```

Is there a special reason why `oneobj` is set to false when we only pass one D source file? For caching work, I want to know whether we are building stuff into one object file, and params.oneobj is apparently not what it says it is ;)

Thanks,
  Johan
November 01, 2016
On Tuesday, 1 November 2016 at 14:01:53 UTC, Johan Engelen wrote:
> Hi all,
>   I just found this in mars.d:
> ```
>   version (IN_LLVM)
>   {
>     if (global.params.oneobj && modules.dim < 2)
>         global.params.oneobj = false;
> ```
>
> Is there a special reason why `oneobj` is set to false when we only pass one D source file? For caching work, I want to know whether we are building stuff into one object file, and params.oneobj is apparently not what it says it is ;)
>
> Thanks,
>   Johan

`-singleobj`, i.e., `global.params.oneobj`, does imply a few special cases. E.g., the single resulting object is always specified before all other existing object files when linking. The object filename may also differ if an output filename has been specified. For these reasons, I chose to clear that flag if the user has only specified a single D module to be compiled (and no `-main`, which implicitly adds a special source module), where -singleobj wouldn't make a semantic difference anyway.

This also makes sure `ldmd2 a.o b.d` results in the linking order `a.o b.o`.
November 01, 2016
Additionally, I think this works around a front-end bug wrt. inferred output filename if there are no source modules at all, i.e., when LDC/LDMD is only used for linking.
November 07, 2016
So, when there's an issue, face it with your team. The earlier you address it, the less problems it will cause.
Again, remember: your teammates are there to back you up in any difficult case.
The trick is that Developers always try their best to help, offering variants and solutions. But they will never know the product as well as you do. Their solutions won't be the most optimal ones http://djangostars.com/blog/
November 07, 2016
On Tuesday, 1 November 2016 at 14:01:53 UTC, Johan Engelen wrote:
> For caching work

Is there more IR-level caching work pending in LDC!?
November 08, 2016
On Monday, 7 November 2016 at 22:17:33 UTC, Nordlöw wrote:
> On Tuesday, 1 November 2016 at 14:01:53 UTC, Johan Engelen wrote:
>> For caching work
>
> Is there more IR-level caching work pending in LDC!?

Source-level caching (`ccache`-like), it's almost done.

-Johan
November 08, 2016
On Tuesday, 8 November 2016 at 05:15:56 UTC, Johan Engelen wrote:
> Source-level caching (`ccache`-like), it's almost done.

Sounds great. I presume (transitive) dependency analysis happens on file-level, right?

What is the motivation behind having this as well, when LDC just got IR-level caching aswell?
November 08, 2016
On Tuesday, 8 November 2016 at 07:51:35 UTC, Nordlöw wrote:
> On Tuesday, 8 November 2016 at 05:15:56 UTC, Johan Engelen wrote:
>> Source-level caching (`ccache`-like), it's almost done.
>
> Sounds great. I presume (transitive) dependency analysis happens on file-level, right?
>
> What is the motivation behind having this as well, when LDC just got IR-level caching aswell?

It is approx. infinity times faster when the source has not changed. ;)
IR-level caching skips optimization and machine codegen.
Source-level caching also skips semantic analysis (which can take a considerable amount of time) and IR codegen+hashing (the hashing requires several seconds for large files).

See https://github.com/ldc-developers/ldc/pull/1871
I plan to write a small article explaining how it works when it is merged.

-Johan