To be fair, makefiles are specifications in a build-tool specific language. But it is one language I already know, and it is one that seems to be well-formed, translates to very definite actions on conditions, and I get to choose those actions. I guess it works for me if I do my part, and I can't really see what CMake does for me that I can't do for myself. On 06/18/2024 08:07 PM, Luther Johnson wrote: > > I don't think any makefiles I've written do all of that. I guess I > don't expect all of that in one place. So i will have some makefiles > that are really portable, because they are very compute-bound or their > interface to the world is something else generic, like files. And then > for more platform-specific parts I would have different makefiles for > different platforms. > > One-button, one command-build (that seems) identical for all > platforms, is not that important to me. And yes, sometimes I write > scripts to do the parts of a build in sequence. And I don't consider > any of this 'hard', but I'm not trying make the builds look like they > are the same, even if they are really quite different. The GNU > ./configure, make model is one model. CMake and other makefile > generators are another. But I have used several compilers or other > general purpose tools that have more than one makefile or build > script, depending on the platform, and I just take the tool for what > it is, and use it. And when I have to debug or change something about > the build, it's MUCH easier to work with makefiles and build scripts > than it is to extend configure scripts, or extend a > build-specification in a build-tool-specific language. In my > experience, so far. But some people will get into configure and/or > CMake or any of the others and learn how to be productive that way. > More power to them, but I don't enjoy doing that. When I have had to > use CMake, it seemed to require more specification on my part to > generate all sorts of crufty state, so every build was not necessarily > the same, unless I used the right commands or deleted all these extra > directories full of persistence from the last CMake or build, to write > all these weird, generated, unreadablemakefiles calling makefiles, > doing no more than I could easily do by hand in one makefile. No, my > hand-written makefiles will not be absolutely universal, or appear to > be, but they will work in a way I can predict, and that is of great > value to me. > > On 06/18/2024 05:46 PM, Nevin Liber wrote: >> On Tue, Jun 18, 2024 at 7:09 PM Luther Johnson >> > >> wrote: >> >> I agree with Greg here. In fact even if it was well done, it is >> declaring something that wasn't really a problem, to be a problem, to >> insert itself as the solution, but I think it's just extra stuff and >> steps that ultimately obfuscates and creates yet more dependencies. >> >> >> That's a really bold claim. You may not like the solution (I don't >> tend to comment on it because unlike some here, I recognize that >> build systems are a Hard Problem and I don't know how to make a >> better solution), but that doesn't mean it isn't solving real problems. >> >> But I'll bite. There was the claim by Larry McVoy that "Writing >> Makefiles isn't that hard". >> >> Please show these beautiful makefiles for a non-toy non-trivial >> product (say, something like gcc or llvm), which make it easy to >> change platforms, underlying compilers, works well with modern >> multicore processors, gets the dependencies right (one should never >> have to type "make clean" to get a build working correctly), etc. and >> doesn't require blindly running some 20K line shell script like >> "configure" to set it up. >> -- >> Nevin ":-)" Liber > iber@gmail.com >> > +1-847-691-1404 >