How do you create a .di file for multiple .d files?
Jonathan M Davis
jmdavisProg at gmx.com
Tue Oct 12 17:50:15 PDT 2010
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
More information about the Digitalmars-d-learn
mailing list