www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Outputting generated .di files to correct module structure

reply "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
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.
Feb 29 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 29 2012
parent "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
Done:
http://d.puremagic.com/issues/show_bug.cgi?id=7610

On Wednesday, 29 February 2012 at 15:35:23 UTC, Andrei 
Alexandrescu wrote:

 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
Feb 29 2012
prev sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Wed, 29 Feb 2012 16:25:32 +0100, Rene Zwanenburg  
<renezwanenburg gmail.com> 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'.


dmd -o- -op -Hdheaders basepkg/pkg1/mod1.d basepkg/pkg2/mod2.d
Feb 29 2012
parent reply "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Wednesday, 29 February 2012 at 18:10:41 UTC, Martin Nowak 
wrote:

 On Wed, 29 Feb 2012 16:25:32 +0100, Rene Zwanenburg 
 <renezwanenburg gmail.com> 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'.


 dmd -o- -op -Hdheaders basepkg/pkg1/mod1.d basepkg/pkg2/mod2.d


Thanks, I just found that out while browsing DMD's source. The 
documentation on http://dlang.org/dmd-windows.html doesn't 
mention it though, says it only works for object files.
Feb 29 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/29/12 12:26 PM, Rene Zwanenburg wrote:

 On Wednesday, 29 February 2012 at 18:10:41 UTC, Martin Nowak wrote:

 On Wed, 29 Feb 2012 16:25:32 +0100, Rene Zwanenburg
 <renezwanenburg gmail.com> 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'.


 dmd -o- -op -Hdheaders basepkg/pkg1/mod1.d basepkg/pkg2/mod2.d


 Thanks, I just found that out while browsing DMD's source. The
 documentation on http://dlang.org/dmd-windows.html doesn't mention it
 though, says it only works for object files.


Does that downgrade the bug report to a documentation bug?

Andrei
Feb 29 2012
parent "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Wednesday, 29 February 2012 at 23:55:05 UTC, Andrei 
Alexandrescu wrote:

 On 2/29/12 12:26 PM, Rene Zwanenburg wrote:

 On Wednesday, 29 February 2012 at 18:10:41 UTC, Martin Nowak 
 wrote:

 On Wed, 29 Feb 2012 16:25:32 +0100, Rene Zwanenburg
 <renezwanenburg gmail.com> 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'.


 dmd -o- -op -Hdheaders basepkg/pkg1/mod1.d basepkg/pkg2/mod2.d


 Thanks, I just found that out while browsing DMD's source. The
 documentation on http://dlang.org/dmd-windows.html doesn't 
 mention it
 though, says it only works for object files.


 Does that downgrade the bug report to a documentation bug?

 Andrei


I've added a patch to the bug report which fixes the 
documentation.
Mar 01 2012