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
