<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>I defer to your greater experience than mine. I guess I've run
      into ./configure && make in very vanilla situations, a few
      Gnu or Gnu-ish applications. If it has times when it doesn't work,
      or doesn't behave well, then I don't doubt your experience.<br>
    </p>
    I first entered this thread in pointing out some similarities in the
    style of opaque artificially pseudo intelligence behind systemd and
    CMake, namely, don't you decide what to do, tell about these
    qualities of these modules and we will decide what to do, don't
    worry your newbie little head. I think autoconf and configure are
    kind of halfway between user-decides-what to do (straight make) and
    user-decides-nothing, is-kept-in the-dark (CMake). So in that way,
    it's only half as bad. If it falls over sometimes when it shouldn't
    I think you know more about that then me. I will be wary.<br>
    <br>
    For my own code, I stick with straight make, and the occasional
    script.<br>
    <br>
    <div class="moz-cite-prefix">On 06/20/2024 02:00 PM, ron minnich
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAP6exY+pHTAoTHjZnDWcSLVcJXWxi4__cMVnCt7on1zEUC4Yzw@mail.gmail.com"
      type="cite">
      <div dir="ltr">here's where I'd have to disagree: "./configure
        && make is not so bad, it's not irrational, sometimes
        it's overkill, but it works"
        <div><br>
        </div>
        <div>because it doesn't. Work, that is. At least, for me.</div>
        <div><br>
        </div>
        <div>I'm amazed: the autoreconf step on slurm permanently broke
          the build, such that I am having to do a full git reset --hard
          and clean and start over. </div>
        <div><br>
        </div>
        <div>Even simple things fail with autoconf: see the sad story
          here, of how I pulled down a few simple programs, and they all
          fail to build. I replaced them ALL with a single Go program
          that was smaller, by far, than a single one of the configure
          scripts. <a moz-do-not-send="true"
href="https://docs.google.com/presentation/d/1d0yK7g-J6oITgE-B_odadSw3nlBWGbMK7clt_TmXo7c/edit?usp=sharing">https://docs.google.com/presentation/d/1d0yK7g-J6oITgE-B_odadSw3nlBWGbMK7clt_TmXo7c/edit?usp=sharing</a></div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Thu, Jun 20, 2024 at
          1:35 PM Luther Johnson <<a moz-do-not-send="true"
            href="mailto:luther.johnson@makerlisp.com">luther.johnson@makerlisp.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div bgcolor="#FFFFFF">
            <p>I agree that there are certainly times when CMake's
              leverage has solved problems for people. My most visceral
              reactions were mostly based on cases where no tool like
              CMake was really required at all, but CMake had wormed its
              way into the consciousness of new programmers who never
              learned make, and thought CMake was doing them a great
              service. Bugged the hell out of me, this dumbing-down of
              the general programming population. My bad experiences
              were all as a consultant to teams that needed a lot of
              expert help, when they had thrown CMake along with a lot
              of other unnecessary complexity into their half-working
              solutions. So I guess it was all tarred by the same flavor
              of badly conceived work. But then as I tried to make my
              peace with the CMake build as it was, I got a deeper
              understanding of how intrinsically irrational CMake is
              (and again, behavior changing on the same builds depending
              on CMake release versions.<br>
            </p>
            So there certainly are times when something a little more
            comprehensive, outside of make, is required. ./configure
            && make is not so bad, it's not irrational,
            sometimes it's overkill, but it works ... but only if the
            system is kind of Unix-y. If not you may wind up doing a lot
            of work to pretend it's more Unix-y, so instead of porting
            your software, you're porting it to a common Unix-like
            subset, then emulating that Unix-like subset on your
            platform, both ends against the middle. That can be
            ultimately counter-productive too.<br>
            <br>
            I have an emotional reaction when I see the porting problem
            become transformed into adherence to the "one true way", be
            it Unix, or one build system or another. Because you're now
            just re-casting the problem into acceptance of that other
            tool or OS core as the way it should be. Instead of getting
            your thing to work on the other platform, by translating
            from what your application wants, into how to do it on
            whatever system, you're changing your application to be more
            like what the "one true system" wants to see. You've given
            up control of your idea of your app's core OS requirements,
            you've decided to "just give in and be UNiX (or Windows, or
            whatever)". To me, that's backwards.<br>
            <br>
            <div>On 06/20/2024 12:59 PM, Warner Losh wrote:<br>
            </div>
            <blockquote type="cite">
              <div dir="ltr">
                <div>For me, precomputing an environment is the same as
                  a wysiwyg editor: what you see is all you get. If it
                  works for you, and the environment that's inferred
                  from predefined CPP symbols is correct, then it's an
                  easy solution. When it's not, and for me it often
                  wasn't, it's nothing but pain and suffering and saying
                  MF all the time (also not Make File)....  I was
                  serious when I've said I've had more positive cmake
                  experiences (which haven't been all that impressive:
                  I'm more impressed with meson in this space, for
                  example) than I ever had with IMakefiles, imake,
                  xmkmf, etc...  But It's also clear that different
                  people have lived through different hassles, and I
                  respect that...</div>
                <div><br>
                </div>
                <div>I've noticed too that we're relatively homogeneous
                  these days: Everybody is a Linux box or Windows Box or
                  MacOS, except for a few weird people on the fringes
                  (like me). It's a lot easier to get things right
                  enough w/o autotools, scons, meson, etc than it was in
                  The Bad Old Days of the Unix Wars and the Innovation
                  Famine that followed from the late 80s to the mid
                  2000s.... In that environment, there's one of two
                  reactions: Test Everything or Least Common
                  Denominator. And we've seen both represented in this
                  thread.  As well as the 'There's so few environments,
                  can't you precompute them all?' sentiment from newbies
                  that never bloodied their knuckles with some of the
                  less like Research Unix machines out there like AIX
                  and HP/UX...  Or worse, Eunice...</div>
                <div><br>
                </div>
                <div>Warner<br>
                </div>
                <br>
                <div class="gmail_quote">
                  <div dir="ltr" class="gmail_attr">On Thu, Jun 20, 2024
                    at 12:42 PM Adam Thornton <<a
                      moz-do-not-send="true"
                      href="mailto:athornton@gmail.com" target="_blank">athornton@gmail.com</a>>
                    wrote:<br>
                  </div>
                  <blockquote class="gmail_quote" style="margin:0px 0px
                    0px 0.8ex;border-left:1px solid
                    rgb(204,204,204);padding-left:1ex">
                    <div dir="ltr">
                      <div style="margin-left:40px"><br>
                      </div>
                      <div style="margin-left:40px"><br>
                      </div>
                      <blockquote style="margin:0px 0px 0px
                        0.8ex;border-left:1px solid
                        rgb(204,204,204);padding-left:1ex"
                        class="gmail_quote">Someone clearly never used
                        imake...</blockquote>
                      <div style="margin-left:40px"><br>
                      </div>
                      <div style="margin-left:40px">There's a reason
                        that the <span style="font-family:monospace">xmkmf
                        </span><font face="arial,sans-serif">command
                          ends in the two letters it does, and I'm never
                          going to believe it's "make file".</font></div>
                      <div style="margin-left:40px"><font
                          face="arial,sans-serif"><br>
                        </font></div>
                      <div style="margin-left:40px"><font
                          face="arial,sans-serif">Adam<br>
                        </font></div>
                    </div>
                    <br>
                    <div class="gmail_quote">
                      <div dir="ltr" class="gmail_attr">On Thu, Jun 20,
                        2024 at 11:34 AM Greg A. Woods <<a
                          moz-do-not-send="true"
                          href="mailto:woods@robohack.ca"
                          target="_blank">woods@robohack.ca</a>>
                        wrote:<br>
                      </div>
                      <blockquote class="gmail_quote" style="margin:0px
                        0px 0px 0.8ex;border-left:1px solid
                        rgb(204,204,204);padding-left:1ex">At Thu, 20
                        Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS
                        <<a moz-do-not-send="true"
                          href="mailto:tuhs@tuhs.org" target="_blank">tuhs@tuhs.org</a>>
                        wrote:<br>
                        Subject: [TUHS] Re: Version 256 of systemd
                        boasts '42% less Unix philosophy' The Register<br>
                        ><br>
                        > "Greg A. Woods" <<a
                          moz-do-not-send="true"
                          href="mailto:woods@robohack.ca"
                          target="_blank">woods@robohack.ca</a>>
                        wrote:<br>
                        ><br>
                        > > I will not ever allow cmake to run, or
                        even exist, on the machines I<br>
                        > > control...<br>
                        ><br>
                        > I'm not a fan of cmake either.<br>
                        ><br>
                        > How do you deal with software that only
                        builds with cmake (or meson,<br>
                        > scons, ... whatever the developer decided
                        to use as the build tool)?<br>
                        > What alternatives exist short of
                        reimplementing the build process in<br>
                        > a standard makefile by hand, which is
                        obviously very time consuming,<br>
                        > error prone, and will probably break the
                        next time you want to update<br>
                        > a given package?<br>
                        <br>
                        The alternative _is_ to reimplement the build
                        process.<br>
                        <br>
                        For example, see:<br>
                        <br>
                                <a moz-do-not-send="true"
                          href="https://github.com/robohack/yajl/"
                          rel="noreferrer" target="_blank">https://github.com/robohack/yajl/</a><br>
                        <br>
                        This example is a far more comprehensive rewrite
                        than is usually<br>
                        necessary as I wanted a complete and portable
                        example that could be used<br>
                        as the basis for further projects.<br>
                        <br>
                        An example of a much simpler reimplementation:<br>
                        <br>
                                <a moz-do-not-send="true"
href="http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN"
                          rel="noreferrer" target="_blank">http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN</a><br>
                        <br>
                        --<br>
                                                                Greg A.
                        Woods <<a moz-do-not-send="true"
                          href="mailto:gwoods@acm.org" target="_blank">gwoods@acm.org</a>><br>
                        <br>
                        Kelowna, BC     +1 250 762-7675         
                         RoboHack <<a moz-do-not-send="true"
                          href="mailto:woods@robohack.ca"
                          target="_blank">woods@robohack.ca</a>><br>
                        Planix, Inc. <<a moz-do-not-send="true"
                          href="mailto:woods@planix.com" target="_blank">woods@planix.com</a>> 
                           Avoncote Farms <<a moz-do-not-send="true"
                          href="mailto:woods@avoncote.ca"
                          target="_blank">woods@avoncote.ca</a>><br>
                      </blockquote>
                    </div>
                  </blockquote>
                </div>
              </div>
            </blockquote>
            <br>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </body>
</html>