www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How do you create a .di file for multiple .d files?

reply Jonathan M Davis <jmdavisProg gmx.com> writes:
Okay, I'm trying to figure out how to take multiple .d files and use a single
.di 
file for them. It looks like if you have x.di file with a corresponding x.d
file 
(so, only one .d file), you put package x; at the top of both files, and dmd is 
able to deal with it, knowing that the .d file holds the implementation for the 
.di file. But what about multiple .d files? I very much doubt that you can put 
package x; at the top of several .d files and have dmd be happy with you. You 
can't do that normally, but maybe you can do that if you have a .di file?

Or is the solution to have a single .d file which corresponds to the .di file
and 
havie it publicly import the other .d files?

Or is the solution something else entirely?

- Jonathan M Davis
Oct 10 2010
next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Jonathan M Davis Wrote:

 Okay, I'm trying to figure out how to take multiple .d files and use a single
.di 
 file for them. It looks like if you have x.di file with a corresponding x.d
file 
 (so, only one .d file), you put package x; at the top of both files, and dmd
is 
 able to deal with it, knowing that the .d file holds the implementation for
the 
 .di file. But what about multiple .d files? I very much doubt that you can put 
 package x; at the top of several .d files and have dmd be happy with you. You 
 can't do that normally, but maybe you can do that if you have a .di file?

I don't use .di files but it sounds like you what to use them for a different purpose then what they are for. The .di is actually telling the linker where it needs to find the functions. If you provide functions from multiple modules, how will the linker know which module to look in to get the code? Also if you have the .d file there is no need for the .di file (they aren't header files). So what is the reason for only wanting one .di file?
Oct 12 2010
next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Jesse Phillips Wrote:

 Jonathan M Davis Wrote:
 
 Okay, I'm trying to figure out how to take multiple .d files and use a single
.di 
 file for them. It looks like if you have x.di file with a corresponding x.d
file 
 (so, only one .d file), you put package x; at the top of both files, and dmd
is 
 able to deal with it, knowing that the .d file holds the implementation for
the 
 .di file. But what about multiple .d files? I very much doubt that you can put 
 package x; at the top of several .d files and have dmd be happy with you. You 
 can't do that normally, but maybe you can do that if you have a .di file?

I don't use .di files but it sounds like you what to use them for a different purpose then what they are for. The .di is actually telling the linker where it needs to find the functions. If you provide functions from multiple modules, how will the linker know which module to look in to get the code? Also if you have the .d file there is no need for the .di file (they aren't header files). So what is the reason for only wanting one .di file?

Reading it again it sounds like you are asking for one thing but describing something different. And one thing is that you use 'module x' not 'package x' I believe the latter will create a variable x which is only viewable with in the package. And note that the module name defaults to the name of the file. A package is a directory of modules (d files). module packageName.moduleName; import packageName.otherModule; is a standard file opening. It says the module exists in packageName and named moduleName, and I would like to use the functions found in the module otherModule under packageName. So if you wish to use functions specified by a .di file in multiple .d files you must import the module, and provide a corresponding object file that contains the code.
Oct 12 2010
prev sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Jonathan M Davis Wrote:

 It's what Walter suggested doing to have a single std.datetime to import but 
 have multiple modules for the actual implementation (he mentioned it in the 
 datetime review thread on the Phobos list). He said to look at druntime for 
 examples, but all of the .di files that I see there appear to have a single .d 
 file corresponding to them. If there is one with multiple .d files, I missed
it.
 
 - Jonathan M Davis

Ah, yes. I thought you had done some big work in D, so I thought it odd you would be confused on modules. I believe you were referring to this part from Walter:
 Remember, if a module's implementation code is large, it can be split
 into a .di/implementation pair, rather than into multiple modules.

And the later follow up.
 Jonathan M Davis wrote:

    Really, the ideal would be to have all of it in one module but have the
code split up into several files. 
 The closest way that I was aware to do that was to use a single module which
publicly imported the 
 others. I'll look at splitting it into an interface file and source file
though.


 druntime does it for several modules, and can serve as an example.

I think I read into that differently. I was thinking he meant that by creating a D interface file you no longer have all the implementation making the file look big. I didn't understand the benefit, nor how it related to the problem. On another note, why does druntime ship with .di files and .d files? Phobos is only .d
Oct 12 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, October 12, 2010 16:07:29 Jesse Phillips wrote:
 Jonathan M Davis Wrote:
 Okay, I'm trying to figure out how to take multiple .d files and use a
 single .di file for them. It looks like if you have x.di file with a
 corresponding x.d file (so, only one .d file), you put package x; at the
 top of both files, and dmd is able to deal with it, knowing that the .d
 file holds the implementation for the .di file. But what about multiple
 .d files? I very much doubt that you can put package x; at the top of
 several .d files and have dmd be happy with you. You can't do that
 normally, but maybe you can do that if you have a .di file?

I don't use .di files but it sounds like you what to use them for a different purpose then what they are for. The .di is actually telling the linker where it needs to find the functions. If you provide functions from multiple modules, how will the linker know which module to look in to get the code? Also if you have the .d file there is no need for the .di file (they aren't header files). So what is the reason for only wanting one .di file?

It's what Walter suggested doing to have a single std.datetime to import but have multiple modules for the actual implementation (he mentioned it in the datetime review thread on the Phobos list). He said to look at druntime for examples, but all of the .di files that I see there appear to have a single .d file corresponding to them. If there is one with multiple .d files, I missed it. - Jonathan M Davis
Oct 12 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, October 12, 2010 16:20:50 Jesse Phillips wrote:
 Jesse Phillips Wrote:
 Jonathan M Davis Wrote:
 Okay, I'm trying to figure out how to take multiple .d files and use a
 single .di file for them. It looks like if you have x.di file with a
 corresponding x.d file (so, only one .d file), you put package x; at
 the top of both files, and dmd is able to deal with it, knowing that
 the .d file holds the implementation for the .di file. But what about
 multiple .d files? I very much doubt that you can put package x; at
 the top of several .d files and have dmd be happy with you. You can't
 do that normally, but maybe you can do that if you have a .di file?

I don't use .di files but it sounds like you what to use them for a different purpose then what they are for. The .di is actually telling the linker where it needs to find the functions. If you provide functions from multiple modules, how will the linker know which module to look in to get the code? Also if you have the .d file there is no need for the .di file (they aren't header files). So what is the reason for only wanting one .di file?

Reading it again it sounds like you are asking for one thing but describing something different. And one thing is that you use 'module x' not 'package x' I believe the latter will create a variable x which is only viewable with in the package. And note that the module name defaults to the name of the file. A package is a directory of modules (d files). module packageName.moduleName; import packageName.otherModule; is a standard file opening. It says the module exists in packageName and named moduleName, and I would like to use the functions found in the module otherModule under packageName. So if you wish to use functions specified by a .di file in multiple .d files you must import the module, and provide a corresponding object file that contains the code.

Yes, I screwed up there. I should have put module x, not package x. But regardless, I'm not looking to use the functions specified in a .di file in multiple files. I'm looking to have the implementation of the functions specified in the .di file to be in multiple files. So, the module that wants to use that functionality imports the .di file's module. I don't want to create a package. I want a single module to import which has its implementation separated into several files. So, the idea is to have a .di file with all of the declarations for the public API of the module, and then have the definitions for them (along with all of the stuff private to the module) split into several files. The only way that I can think of doing so is to have a single .di file with a single corresponding .d file which publicly imports the .d files with the implementation. What I'd like to know is whether that is the correct way to do that or whether there is another way. - Jonathan M Davis
Oct 12 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, October 12, 2010 18:16:04 Jesse Phillips wrote:
 Jonathan M Davis Wrote:
 It's what Walter suggested doing to have a single std.datetime to import
 but have multiple modules for the actual implementation (he mentioned it
 in the datetime review thread on the Phobos list). He said to look at
 druntime for examples, but all of the .di files that I see there appear
 to have a single .d file corresponding to them. If there is one with
 multiple .d files, I missed it.
 
 - Jonathan M Davis

Ah, yes. I thought you had done some big work in D, so I thought it odd you

Yeah. I understand modules well enough (though I'm not particularly familiar with .di files). I just screwed up in my post.
 I believe you were referring to this part from Walter:
 Remember, if a module's implementation code is large, it can be split
 into a .di/implementation pair, rather than into multiple modules.

And the later follow up.
 Jonathan M Davis wrote:
    Really, the ideal would be to have all of it in one module but have
    the code split up into several files.
 
 The closest way that I was aware to do that was to use a single module
 which publicly imported the others. I'll look at splitting it into an
 interface file and source file though.

druntime does it for several modules, and can serve as an example.

I think I read into that differently. I was thinking he meant that by creating a D interface file you no longer have all the implementation making the file look big. I didn't understand the benefit, nor how it related to the problem.

Ah, and re-reading what he said, he wasn't suggesting that I have multiple .d files with a single .di file but rather that I have a single .di and single .d file. I misunderstood. That would explain why I couldn't find any code in druntime which was splitting the implementation for a .di file into multiple files. The public imports in the .d file might still work as I suggested though. I'll look at using a single .d file though as see how big that is before I consider splitting them.
 On another note, why does druntime ship with .di files and .d files? Phobos
 is only .d

I think that this has come up and been answered before, but unfortunately, I don't recall what the reason was. I'd have to search through the archives to find it. It does seem a bit odd though. - Jonathan M Davis
Oct 12 2010