Outputting generated .di files to correct module structure

[Andrei Alexandrescu]

On 2/29/12 9:25 AM, Rene Zwanenburg wrote:
> The project I'm currently working on is becoming quite large, and is
> being compiled to a few different lib files. This is useful, so the
> application and tools only have to link to the libraries they need.
>
> We use DMD's interface generation option to create the header files,
> which is an awesome feature, but the problem is that it doesn't output
> interface files in the package hierarchy. For example, if there are two
> modules 'basepackage/package1/module1.d' and
> 'basepackage/package2/module2.d', the interfaces end up as
> 'headers/module1.di' and 'headers/module2.di'.
>
> Now, when we add the 'headers' directory to the include path, the
> compiler won't be able to find module1 when importing
> 'basepackage/package1/module1'. It works when I simply import 'module1',
> which surprises me since the interface retains the original module
> declaration.
>
> Anyway, DMD not outputting interfaces in the package hierarchy makes the
> feature pretty much useless for large projects. Is there a reason for
> this behavior, or was this simply never considered? I'm willing to try
> and add a new switch to the compiler so it creates the hierarchy, but
> I've never touched DMD's source so I'm not sure if I'm the right person
> for the job.

I'd put this bug together with the recently-discussed bug that the 
object file names clash when coming from different packages, in the same 
bin - the "growing pains" bin.

A lot of stuff has been thought for large modular projects in D, but 
until recently that boundary hasn't been pushed strongly enough. 
Therefore, a lot of small logistical details like this one were not paid 
attention to.

Rene, could you please submit this bug to our bugzilla with importance 
"critical"? I think this is an important category of bugs because it 
stymies progress for D's most invested users.


Thanks,

Andrei