dmd compile with imported modules

[Jonathan M Davis]

On Saturday 01 January 2011 07:07:12 spir wrote:
> On Sat, 1 Jan 2011 13:34:47 +0000 (UTC)
> 
> useo <useo at start.bg> wrote:
> > Hey guys,
> > 
> > I've the following problem... when I write a simple class, for
> > example:
> > 
> > ...
> > module myclasses.exampleClass;
> > 
> > class exampleClass {
> > void writeHelloWorld() {
> > writeln("Hello World");
> > }
> > 
> > And import myclasses.exampleClass in the following:
> > 
> > ...
> > module mainfile;
> > 
> > import myclasses.exampleClass;
> > 
> > void main(string[] args) {
> > exampleClass ec = new exampleClass();
> > ec.writeHelloWorld();
> > }
> > ...
> > 
> > I always have to compile the mainfile-module with "dmd mainfile.d
> > myclasses/exampleClass.d" because of the obj-files. My projects are
> > always growing and I don't want list all 100 or more classes/files in
> > the command line. Is there any possibility to automatically import,
> > compile and link all the files with a short command?
> > 
> > Thanks in advance!
> 
> dmd automatically builds with imported modules from the std lib, but only
> them. rdmd is what you're looking for: see
> http://www.digitalmars.com/d/2.0/rdmd.html. It will forward dmd's
> command-line switches correctly. For instance, my dev-time build command
> is: rdmd -w -debug -unittest --build-only -of"%e" "%f"
> where %e is source filename with ext, %f without ext.

dmd automatically looks for all modules on its build path as far as importing 
goes. dmd.conf puts libphobos on the build path. And your own modules will be 
found to be imported as long as they're in the proper place. e.g. If you're 
building module a which imports module l.m.n and you have this directory 
structure

a.d
l/m/n.d

and you compile dmd a.d, l.m.n will be found to be imported for building a.d. 
So, for instance, dmd -c a.d would work just fine even though you didn't specify 
where l.m.n is. However, you didn't tell it to build l/m/n.d, so it didn't build 
it. It only imported it. No object file was generated for it, and it wasn't 
linked in. For that, you must explicitly tell dmd to build it. e.g. dmd a.d 
l/m/n.d. You don't have to do that far libphobos because it's already been built 
and the library is listed in dmd.conf.

The situation is similar to what you'd get with gcc in C or C++. The header files 
on the include path is found, but the source files aren't compiled unless you 
specifically compile them. It's the same in D, except that the header and source 
files are generally the same file. The file is found and used for importing but is 
not actually compiled into the binary unless it is explicitly compiled. Like in 
C++, build tools like make must be used. There are several options for D2 
(though not as many as for D1, I don't believe), but I'm not all that well 
versed on what they are, because my projects are generally small, and so a build 
is generally unnecessary (listing each file doesn't take much even if I am using 
a module hierarchy).

- Jonathan M Davis