<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>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.<br>
    </p>
    <div class="moz-cite-prefix">On 06/18/2024 08:07 PM, Luther Johnson
      wrote:<br>
    </div>
    <blockquote
      cite="mid:a6e1b2d5-f52b-0365-1b73-6844d18e3c6f@makerlisp.com"
      type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      <p>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.<br>
      </p>
      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.<br>
      <br>
      <div class="moz-cite-prefix">On 06/18/2024 05:46 PM, Nevin Liber
        wrote:<br>
      </div>
      <blockquote
cite="mid:CAGg_6+P8h+czyXx0uxPDSJKUtWsMjsbD6ZGwJtHDbmiFvgxFTw@mail.gmail.com"
        type="cite">
        <div dir="ltr">
          <div dir="ltr">On Tue, Jun 18, 2024 at 7:09 PM Luther Johnson
            <<a moz-do-not-send="true"
              href="mailto:luther.johnson@makerlisp.com">luther.johnson@makerlisp.com</a>>
            wrote:<br>
          </div>
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I
              agree with Greg here. In fact even if it was well done, it
              is<br>
              declaring something that wasn't really a problem, to be a
              problem, to<br>
              insert itself as the solution, but I think it's just extra
              stuff and<br>
              steps that ultimately obfuscates and creates yet more
              dependencies.<br>
            </blockquote>
            <div><br>
            </div>
            <div>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.</div>
            <div><br>
            </div>
            <div>But I'll bite.  There was the claim by Larry McVoy that
              "Writing Makefiles isn't that hard".</div>
            <div><br>
            </div>
            <div>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.</div>
          </div>
          <span class="gmail_signature_prefix">-- </span><br>
          <div dir="ltr" class="gmail_signature">
            <div dir="ltr">
              <div> Nevin ":-)" Liber  <mailto:<a
                  moz-do-not-send="true"
                  href="mailto:nevin@eviloverlord.com" target="_blank">nl</a><a
                  moz-do-not-send="true" href="mailto:iber@gmail.com"
                  target="_blank">iber@gmail.com</a>> 
                +1-847-691-1404</div>
            </div>
          </div>
        </div>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>