Compiling multiple source files --- each file separately, or all together?

[Richard (Rikki) Andrew Cattermole]

On 28/12/2025 10:33 AM, David Given wrote:
> On Friday, 26 December 2025 at 14:33:48 UTC, monkyyy wrote:
>> Its not the 1970's
> 
> Gosh, is it? I did not know that!
> 
> On Friday, 26 December 2025 at 16:33:14 UTC, H. S. Teoh wrote:
>> The D compiler compiles all source files together. In some cases it's 
>> able to optimize across files when compiled this way, as opposed to 
>> when compiled separately (but not necessarily so; imported files will 
>> still be parsed and analysed, just some parts of codegen may not run 
>> when the imported file isn't listed on the command-line).
>>
>> This applies to all D compilers.
> 
> Excellent, thanks; that's what I was hoping.
> 
> It looks like what I'll do is treat it like Java, where groups of source 
> files are bundled together into compilable units for dependency 
> management (libraries and the like). The fact that multiple source files 
> can be compiled into a _single_ `.o` file may or may not be desirable. 
> I'll have to bundle the `.di` files as part of the build artifact 
> anyway, so having multiple `.o` files doesn't complicate anything; is 
> there any benefit to the compiler to using a single `.o` file? e.g. 
> fewer copies of shared code?
> 
> One thing which looks like it'll complicate matters is the handling of 
> `.di` files. AFAICT the compiler needs to see them in specific places so 
> that it can find them, so that the `.di` file for the package 
> `foo.bar.baz` needs to be in `foo/bar/baz.di` relative to the search 
> path. But when they're written with `-H`, the prefix directories aren't 
> written automatically, so I need `-Hd=$(OBJ)/foo/bar` or the equivalent 
> --- i.e. the build system needs to know the package path of the file 
> it's compiling.
> 
> This is bad for several reasons, not least that it scuppers the ability 
> to do build files from multiple directories together. I could parse the 
> source files to find the module line but that's horrible. Are there any 
> convenient ways around this? e.g. a way I can tell the compiler where 
> `$(OBJ)` is and have it create any `foo/bar` as necessary?
> 
> Thanks!

Two things:

1. The .di generator runs before semantic analysis, there are no 
inferred attributes in its output. This can effect mangling.

2. You want the -op switch with the .di generator set to a new 
directory. Its in dmd ~master, but ldc has it.