Have Win DMD use gmake instead of a separate DMMake makefile?

Jonathan M Davis jmdavisProg at gmx.com
Sun Aug 11 21:36:20 PDT 2013


On Sunday, August 11, 2013 20:07:17 H. S. Teoh wrote:
> On Sun, Aug 11, 2013 at 06:14:18PM -0700, Jonathan M Davis wrote:
> > On Sunday, August 11, 2013 15:38:09 H. S. Teoh wrote:
> > > Maybe my previous post didn't get the idea across clearly, so let me
> > > try again. My underlying thrust was: instead of maintaining 3
> > > different makefiles (or more) by hand, have a single source for all
> > > of them, and write a small D program to generate posix.mak,
> > > win32.mak, win64.mak, whatever, from that source.
> > > 
> > > That way, adding/removing files from the build, etc., involves only
> > > editing a single file, and regenerating the makefiles/whatever we
> > > use.  If there's a problem with a platform-specific makefile, then
> > > it's just a matter of fixing the platform-specific output handler in
> > > the D program.
> > > 
> > > The way we're currently doing it essentially amounts to the same
> > > thing as copy-n-pasting the same piece of code 3 times and trying to
> > > maintain all 3 copies separately, instead of writing a template that
> > > can be specialized 3 times, thus avoiding boilerplate and
> > > maintenance headaches.
> > 
> > But if you're going that far, why not just do the whole thing with D
> > and ditch make entirely? If it's to avoid bootstrapping issues, we're
> > going to have those anyway once we move the compiler to D (which is
> > well on is well underway), so that really isn't going to matter.
> 
> [...]
> 
> If you like, think of it this way: the build tool will be written in D,
> with the option of generating scripts in legacy formats like makefiles
> or shell scripts so that it can be bootstrapped by whoever needs it to.
> 
> We pay zero cost for this because the source document is the input
> format for the D tool, and the D tool takes care of producing the right
> sequence of commands. There is only one place to update when new files
> need to be added or old files removed -- or, if we integrate it with
> rdmd fully, even this may not be necessary. When somebody asks for a
> makefile, we just run the program with --generate=makefile. When
> somebody asks for a shell script, we just run it with
> --generate=shellscript. The generated makefiles/shell scripts are
> guaranteed to be consistent with the current state of the code, which is
> the whole point behind this exercise.

But what is the point of the makefile? As far as I can see, it gains you 
nothing. It doesn't help bootstrapping at all, because dmd itself will soon be 
written in D and therefore require that a D compiler already be installed. And 
the cost definitely isn't zero, because it requires extra code to be able to 
generate a makefile on top of doing the build purely with the D script (and I 
fully expect that donig the build with the D script will be simpler than 
generating the makefile would be). I see no benefit whatsoever in generating 
makefiles from a D script over simply doing the whole build with the D script. 
There would be an argument for it if dmd itself were going to stay in C++, 
because then you could avoid a circular dependency, but dmd is being converted 
to D, and so we're going to have that circular dependency anyway, negating 
that argument.

- Jonathan M Davis


More information about the Digitalmars-d mailing list