21 Jun
2024
21 Jun
'24
2:34 a.m.
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 <athornton(a)gmail.com
<mailto:athornton@gmail.com>> 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 <woods(a)robohack.ca
<mailto:woods@robohack.ca>> wrote:
At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS
<tuhs(a)tuhs.org <mailto:tuhs@tuhs.org>> wrote:
Subject: [TUHS] Re: Version 256 of systemd boasts '42% less
Unix philosophy' The Register
(or meson,
"Greg A. Woods" <woods(a)robohack.ca
<mailto:woods@robohack.ca>> 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 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…
--
Greg A. Woods
<gwoods(a)acm.org <mailto:gwoods@acm.org>>
Kelowna, BC +1 250 762-7675 RoboHack
<woods(a)robohack.ca <mailto:woods@robohack.ca>>
Planix, Inc. <woods(a)planix.com <mailto:woods@planix.com>>
Avoncote Farms <woods(a)avoncote.ca <mailto:woods@avoncote.ca>>