On Wed, Sep 24, 2014 at 10:23:48PM -0700, Walter Bright via Digitalmars-d wrote: > On 9/24/2014 10:08 PM, H. S. Teoh via Digitalmars-d wrote: > >If you like building real airplanes out of Lego pieces, be my guest. > >Me, I prefer using more suitable tools. :-P > > I spend very little time fussing with make. Making it work better > (even to 0 cost) will add pretty much nothing to my productivity.
Oh? Let's see. One time, while git bisecting to track down a dmd regression, I was running into all sorts of strange inconsistent behaviour from dmd. After about a good 15-30 mins' worth of frustration, I tracked down the source of the problem to make not cleaning up previous .o files, and thus producing a corrupted dmd which contained a mixture of who knows what versions of each .o left behind from previous git bisect steps. So I realized that I had to do a make clean every time to ensure I'm actually getting the dmd I think I'm getting. Welp, that just invalidated my entire git bisect session so far. So git bisect reset and start over. Had dmd used a reliable build system, I wouldn't have wasted that time, plus I'd have the benefit of incremental builds instead of the extra time spent running make clean, and *then* rebuilding everything from scratch. Yup, it wouldn't *add* to my productivity, but it certainly *would* cut down on my *unproductivity*! Now, dmd's makefile is very much on the 'simple' end of the scale, which I'm sure you'll agree if you've seen the kind of makefiles I have to deal with at work. Being simple means it also doesn't expose many of make's myriad problems. I've had to endure through builds that take 30 minutes to complete for a 1-line code change (and apparently I'm already counted lucky -- I hear of projects whose builds could span hours or even *days* if you're unlucky enough to have to build on a low-end machine), only to find that the final image was corrupted because somewhere in that dense forest of poorly-hackneyed makefiles in the source tree somebody had forgotten to cleanup a stray .so file, which is introducing the wrong versions of the wrong symbols to the wrong places, causing executables to go haywire when deployed. Not to mention that some smart people in the team have decided that needing to 'make clean' every single time following an svn update is "normal" practice, thus every makefile in their subdirectory is completely broken, non-parallizable, and extremely fragile. Hooray for the countless afternoons I spent fixing D bugs instead of doing paid work -- because I've to do yet another `make clean; make` just to be sure any subsequent bugs I find are actual bugs, and not inconsistent builds caused by our beloved make. You guys should be thankful, as otherwise I would've been too productive to have time to fix D bugs. :-P And let's not forget the lovely caching of dependency files from gcc that our makefiles attempt to leverage in order to have more accurate dependency information -- information which is mostly worthless because you have to make clean; make after making major changes anyway -- one time I didn't due to time pressure, and was rewarded with another heisenbug caused by stale .dep files causing some source changes to not be reflected in the build. Oh yeah, spent another day or two trying to figure that one out. Oh, and did I mention the impossibility of parallelizing our builds because of certain aforementioned people who think `make clean; make` is "normal workflow"? I'd hazard to guess I could take a year off work from all the accumulated unproductive times waiting for countless serial builds to complete, where parallelized builds would've saved at least half that time, more on modern PCs. Reluctance to get rid of make is kinda like reluctance to use smart pointers / GC because you enjoy manipulating raw pointers in high-level application code. You can certainly do many things with raw pointers, and do it very efficiently 'cos you've already memorized the various arcane hacks needed to make things work over the years -- recite them in your sleep even. It's certainly more productive than spending downtime learning how to use smart pointers or, God forbid, the GC -- after you discount all the time and effort expended in tracking down null pointer segfaults, dangling pointer problems, memory corruption issues, missing sizeof's in malloc calls, and off-by-1 array bugs, that is. To each his own, I say. :-P T -- People tell me that I'm skeptical, but I don't believe them.
