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" because it doesn't. Work, that is. At least, for me. 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. 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. https://docs.google.com/presentation/d/1d0yK7g-J6oITgE-B_odadSw3nlBWGbMK7clt_TmXo7c/edit?usp=sharing On Thu, Jun 20, 2024 at 1:35 PM Luther Johnson wrote: > 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. > 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. > > 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. > > On 06/20/2024 12:59 PM, Warner Losh wrote: > > 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... > > 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... > > Warner > > On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton > wrote: > >> >> >> Someone clearly never used imake... >> >> >> There's a reason that the xmkmf command ends in the two letters it does, >> and I'm never going to believe it's "make file". >> >> Adam >> >> On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods wrote: >> >>> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS >>> wrote: >>> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix >>> philosophy' The Register >>> > >>> > "Greg A. Woods" wrote: >>> > >>> > > I will not ever allow cmake to run, or even exist, on the machines I >>> > > control... >>> > >>> > I'm not a fan of cmake either. >>> > >>> > How do you deal with software that only builds with cmake (or meson, >>> > scons, ... whatever the developer decided to use as the build tool)? >>> > What alternatives exist short of reimplementing the build process in >>> > a standard makefile by hand, which is obviously very time consuming, >>> > error prone, and will probably break the next time you want to update >>> > a given package? >>> >>> The alternative _is_ to reimplement the build process. >>> >>> For example, see: >>> >>> https://github.com/robohack/yajl/ >>> >>> This example is a far more comprehensive rewrite than is usually >>> necessary as I wanted a complete and portable example that could be used >>> as the basis for further projects. >>> >>> An example of a much simpler reimplementation: >>> >>> >>> 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 >>> >>> -- >>> Greg A. Woods >>> >>> Kelowna, BC +1 250 762-7675 RoboHack >>> Planix, Inc. Avoncote Farms >>> >> >