pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: wm/ctwm without cmake

At Wed, 09 Mar 2022 08:58:44 -0500, Greg Troxel <> wrote:
Subject: Re: wm/ctwm without cmake
>   While I see cmake as a regression from
> autoconf/automake, pkgsrc should not be trying to replace upstream's
> build system.

I'm obviously not a lead pkgsrc developer, but I would argue that's
exactly what pkgsrc can and should do whenever and wherever it makes
any subject package more easily supported in pkgsrc.

For me personally that means for all CMake-using packages I'm interested
in using, but it could even include other over-bearing heavy-weight
build systems which are more burden to build and use than the subject
package might be.

> The bloat is one thing, but the culture of OS-ifdefed
> non-portable and rpath-messy cmake build scripts is in my view the
> biggest issue.

I would strongly argue that everything about CMake is unmaintainable and
unusable.  Full stop.  The bloat of the thing is actually the least of
its problems, though obviously it is at the extreme of bloat given what
it actually has to do.

It is the worst disaster in software configuration and construction
tools I've ever seen or heard about.  It seriously feels like it was
designed by amateurs with little to no experience in any aspect of
software development, and it completely ignores all lessons of all past
and existing similar tools.  Even PHP was a better designed language
right from the beginning, and it was designed by a self-admitted
software amateur who was actually a chemistry student!

> I personally think trying to fight upstreams about build system choices
> is not a good use of time.  Your call with your time of course.  I find
> it more efficient to fix upstream cmakefiles.

Well I will personally be replacing uses of CMake in all software I care
about, either by hacking pkgsrc, and/or by forking the upstream package,
just as I've already done in a couple of cases.

Whether others are interested in my efforts or not, well finding that
out is kind of why I posted.

> With pkgsrc, we need to be mindful of the costs of such things: carrying
> patches, especially the cost of bringing them forward, and the
> difficulty of users reporting bugs to upstream who will ask that the
> program be built with upstream's native build procedure.

Yeah, well I argue the cost of trying to maintain build-related patches
to CMake-using packages is higher in many cases than simply re-writing
their builds with simple BSD Makefiles.  And I've seen that there are an
excessive number of CMake-related patches in pkgsrc already.

The cost of maintaining a separate build system might be higher some
huge and/or complex packages like, say, LLVM/Clang, or maybe even
something like Wireshark, but for the likes of ctwm and other similar
packages which are almost pure simple C with few, if any, system-
specific configuration complications, it's trivial to maintain BSD
Makefiles.  Other medium complex things might benefit from configure
scripts, though CMake users are making their packages increasingly more
complex and convoluted to support in this aspect, perhaps due to the
twisted path CMake leads them down.  Ctwm is an excellent micro-example
of this, as the choice of CMake has lead to a mess of inconsistency and
complexity in the build of what is otherwise clearly a very simple and
straight forward piece of software.

But I don't expect to convince everyone, or necessarily even many.

> If you just meant: I did this, and here it is in case anybody else wants
> it, that's fine.
> If you meant: please switch pkgsrc to use this, then I don't think we
> should do that.

Both, but primarily the former, and then as a conversation starter for
the latter.

The biggest problem I have right now with pkgsrc are with those packages
which still maintain alternative build systems and don't force reliance
on CMake, but where the pkgsrc maintainer has blindly chosen the CMake
path for whatever reason.

Now with ctwm the choice of not using the supplied "minibuild" stuff was
possibly excusable, and there's at least one other similar package where
the supplied alternative is also effectively useless, but I've already
reverted a number of other packages back to using their supplied
configure and makefiles.

So the one thing I do seriously ask pkgsrc maintainers and developers to
do is this:  Please do NOT choose to use CMake for a package in pkgsrc
if the package offers _any_ other _viable_ build system support!  If
nothing else this will make me very happy of course, but I believe it
will also help send a message to those package developers who appear to
still be sitting on the fence, that the plain simple Makefile side of
the fence has active supporters.

					Greg A. Woods <>

Kelowna, BC     +1 250 762-7675           RoboHack <>
Planix, Inc. <>     Avoncote Farms <>

Attachment: pgpYlErHKD3qj.pgp
Description: OpenPGP Digital Signature

Home | Main Index | Thread Index | Old Index