At Wed, 9 Mar 2022 09:55:36 +0100, Benny Siegert <bsiegert%gmail.com@localhost> wrote: Subject: Re: wm/ctwm without cmake > > I think I see where you are coming from, but let me warn you that this > kind of stance will not work in the long run. I vividly remember a > fellow developer of an open source project being extremely opposed > about SATA hard drives in PCs (as opposed to PATA). Gradually, it > became harder for him to replace broken hardware, as all new drives > became SATA-only. > > You can see the same thing happening here, in a way. I don't think your analogy holds water. Software tools don't (usually) disappear or even stop being usable. > You want to use > ctwm but you don't like its build system, so you write your own. If > you continue like this, half of pkgsrc will become unusable for you > because of its cmake dependency, unless you rewrite everyone's build > systems. Yes, and I will, though perhaps the shine will go off CMake and it will not become too pervasive. > And now for some cmake apologism: Yes, the cmake package itself is a > bloated C++ codebase. However, in the realm of today's builds, it > barely registers, compared to LLVM, Rust and Firefox. Well its bloat is absolutely horrible, especially in context with what it does, but it's not even the main problem CMake suffers from. > And cmake does have some very tangible benefits when building > packages: First, configure scripts really are the majority of the > build times on modern hardware (including such lower-end machines as > the Pinebook Pro). cmake configures quite a bit faster. The resulting > builds also run faster: unlike most automake-based builds, the cmake > Makefiles manage to saturate the 8 threads of my amd64 machine > consistently. It might be fast at doing some things, but computer time is not very expensive compared to programmer time. > The cmake command language is a bit weird but not more so than > configure.ac and Makefile.am. Sorry, but I find it isn't a command language at all -- it breaks too many de facto rules and expectations to be anything other than a bad poorly conceived hack. Even that problem might be excusable if it provided an otherwise elegant solution to the problems it claims to approach, but it does not. It's a total mess through and through. -- 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:
pgpWSwjEGzSSp.pgp
Description: OpenPGP Digital Signature