dmake is a small commandline utility (<900 lines of D) that can be used to build applications and to develop freely within a system of unified source trees without thinking about library or project borders. Basically you enter "dmake mainsource" and dmake does the rest, it analyzes all import statements recursively and passes all necessary files to dmd to compile and/or link.

Goal statement:

dmake is built for quick, easy and open development in the community. Target groups: people who want to share their sources seemlessly, people who want to learn and work their way into D.

dmake passes all unknown options to dmd, so you can use all dmd options as usual

dmake resolves cyclic dependencies

Precondition:

The dmd configfiles must be in the standard locations.

Windows: c:\dmd\bin\sc.ini (this will be configurable in the next revision)

Linux: /etc/dmd.conf

The configfile DFLAGS options must not (Windows) contain a reference to the relative dmd path (%@P%). Replace this with absolute paths.

The sourcefiles have to be aligned. To work correctly, dmake must be able to find sourcefiles from their module names. So all (almost all) files must be "aligned" to one of the source trees. That means their paths, e.g. "c:\d\project\mod\foo.d" must be a kind of concatenation consisting of one of the import roots (e. g. "c:\d") and the import module names (e.g. "import project.mod.foo;").

Advantages:

you can create projects and examples very quickly

you needn't care for D-libraries, library borders, project borders

in a certain setting you can do code harvesting (move modules and functions around the source tree) without a need to update anything (makefiles, libraries, ...)

Disadvantages:

dmake will not (yet) help you to create libraries, if you want to do that, use digc

Known possible problems:

Linux-dmd doesn't seem to support a response file, so currently all filenames are passed to dmd on the command line. So there is a practical limit to the number of files in the application depending on their accumulated path lengths (maybe 100-200 files). But before someone gets near that limit, the problem will have been solved.

dmake currently ignores Phobos sources by matching file paths to /phobos/ (or \phobos\ respectively) . It leaves it to dmd to resolve that from its library. If someone wants to do active Phobos development, dmake should be enhanced to support that by turning this feature off and solving all related problems.

dmake will currently not read configuration files from nonstandard locations (in that case you have to use dmd -I options to tell dmake where to search).

Support:

I promise to quickly (within a few days) resolve any problems that are reported to me.

I promise to accept enhancements unbureaucratically

Problems or suggestions can be reported here, in the newsgroup, or by e-mail: MAIL helmut.leitner (AT) chello.at

Questions

Q. How does digc and dmake compare:

A. First, dmake uses substancial parts from digc - Thank you, Burton Radons! If the features of dmake become popular, I'm sure Burton will join its features into digc, and I'll be happy to support that. Currently dmake is a
stripped down spike that follows a quite different philosophy.

Comparison chart:

digc

dmake

status

reliable product

late alpha / early beta

philosophy

make library building and using easy

forget about library building and using

goals

to support the creation of proprietary and professional library products and projects that use these libraries

to support easy code reuse across the traditional borders of libraries and projects and for easy change of these structures

target groups

everybody, especially professionals

community projects, newcomers, especially those that want to reuse and share code with a minimum of effort