At Wed, 09 Mar 2022 08:58:44 -0500, Greg Troxel <gdt%lexort.com@localhost> 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 <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpYlErHKD3qj.pgp
Description: OpenPGP Digital Signature