Hi, I was asked off-list to post a lengtly post-note added to a bug report about the segfault of svn 1.14.5 in uri_escape() as a reply to this old thread, so it is in proper context and may be read with that in mind. So here I am quoting myself in reply to this:
am Sat, 27 Jul 2024 21:23:54 +0200 schrieb Daniel Sahlberg <daniel.l.sahlb...@gmail.com>: > Den tis 11 juni 2024 kl 04:29 skrev Nathan Hartman <hartman.nat...@gmail.com > >: > > > [...] It would be nice to hear > > from binary packagers. Will they overwhelmingly say "yes please! It's > > about time!" Or will they say, "Please don't, it would create too much > > headache and I couldn't go on providing packages because of it." > > > > I think this was a good suggestion but I don't think anyone picked up on > this. > > I'm suggesting to send a directed e-mail to the package maintainers for a > handful of distributions asking for their feedback and also experience from > other projects switching build system (do's and dont's). [After description of bug in https://lists.apache.org/thread/g6fm25kfw9t55rbooob7lqc1vn2h2hbx] PS: This svn build was created withing the pkgsrc framework, where I do a bit of packaging (but not specifically the subversion package(s)). I just re-viewed the discussion about switching to CMake for the build system of subversion and the idea of asking distro packagers about their opinion, thread starting at https://lists.apache.org/thread/66lf0c5oyzyhfss6qzmtkb3v866y4dts . This was some time ago, but as I recently had to admit defeat trying to get a CMake-based scientific software build to accept my installed Boost, on top of various hurtful experience with rotting CMake builds (rotting in the sense of 'bit rot': code getting outdated, modern cmake and dependencies shifting, breaking stuff), I want to add a note that I really would like projects to either keep perfectly working autotools builds or switch to something else than CMake. CMake's strongest point is the huge network effect. The fact that one motivation for the CMake port was to align with the build system of subversion dependencies is a warning sign (even though I don't see cmake in the dependencies of subversion in pkgsrc at least). The build system of your dependencies should not matter. Ideally, the build system should not matter at all to the user. It should be orthogonal to the others, and not get in the way, playing with minimal interfaces. CMake is for integrating things under one rule. CMake builds have a history of collecting lots of custom hacks and each project working somewhat differently regarding things that used to have clear conventions with autotools builds, or even simpler systems. CMake's preference for handling libraries as /path/to/libfoo.so instead of -lfoo, along with idiosyncracies about rpath handling make controlling a build hard at times, especially for my use case that needs prefixes and library locations via RPATH/RUNPATH (preference for the former, a whole different discussion). When there are working pkg-config files and things like CFLAGS, LDFLAGS, CPATH, LD_RUN_PATH, LIBRARY_PATH etal. that make the compiler happy if nothing intervenes, the separate structure of .cmake config files for dependencies causes quite some headache — they make things simpler for Windows and individual (commercial, in-house) projects, probably, but are just added complexity on a Unix system/distribution context. This is gettin too long for a footnote, sorry. CMake-using projects have cost me a lot of happy neurons that shrieked and died in despair. This is not necessarily CMake itself, but the practices it bred. Please just make it behave nicely on Unix, respecting envionment variables, using pkg-config for dependencies. And try to keep any custom code really to a minimum — packagers get nightmares from expeditions into caves of custom cmake detection logic. Try not to be smart detecting stuff and always be prepared to let the user override things by setting variables. Do not use facilities of CMake to downlaod and build dependencies. Be prepared that things stop working in a few years as CMake policies come an go, things being deprecated and introduced. Shipping the build system (autotools generated scripts) with the sources has an advantage there: You don't have to work with the build system binary _I_ bring to the game, which might not like your setup anymore (like a number of projects needing new releases when CMake 4.x enters the scene). One nice example of CMake breaking your build is in json-c-0.18 (released last September). $ cd json-c-0.18 && cmake . # yes, it still supports in-tree build;-) CMake Deprecation Warning at tests/CMakeLists.txt:1 (cmake_minimum_required): Compatibility with CMake < 3.10 will be removed from a future version of CMake. Update the VERSION argument <min> value. Or, use the <min>...<max> syntax to tell CMake that the project requires at least <min> but has been updated to work with policies introduced by <max> or earlier. CMake Error at apps/CMakeLists.txt:2 (cmake_minimum_required): Compatibility with CMake < 3.5 has been removed from CMake. Update the VERSION argument <min> value. Or, use the <min>...<max> syntax to tell CMake that the project requires at least <min> but has been updated to work with policies introduced by <max> or earlier. Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway. -- Configuring incomplete, errors occurred! You see one mine exploding and the other ticking: $ head -n 1 tests/CMakeLists.txt cmake_minimum_required(VERSION 3.9) $ head -n 2 apps/CMakeLists.txt | tail -n 1 cmake_minimum_required(VERSION 2.8) # see ../CMakeLists.txt for why 2.8 Does CMakeLists.txt say something about that? $ head -n 6 CMakeLists.txt # CMake 3.9 was released in 2017/07 # As of 2023, many versions of Linux, NetBSD and FreeBSD provide, # and many OpenWRT packages require, much newer CMake packages. # We're stopping before 3.10 because that version starts requiring # c++11, which isn't available on e.g HPUX. cmake_minimum_required(VERSION 3.9...3.12) Doesn't seem so. You as upstream have to invest continuous work to keep up with the cmake ecosystem, breaking your builds on the end-users/packagers machines, not just during release preparation. You really need to watch out for the legacy of CMake code you're collecting and ensure that you have someone ready who can fix it in 5 years. Or rather … users (packagers) will have to fix it. Even without subversion development and releases, development work is necessary on the build system, even for something innocent as requiring a minimum version that is too minimal. Also have fun with bisecting builds, where you may need older cmake versions around or older releases. PPS: Sorry again for hijacking my own thread. I could write an even longer essay about what irks me about CMake practices, and maybe of development practices of scientific sofware in particular, which often is intermittend abandonware by definition (of the employment structure of scientists). No need to lengthy replies. Just wanted to give my perspective and a little warning. [Adding one more, not included in the referenced post.] PPPS: Note that the general issue of relying on the version of the build tool on the user's machine is a fault that also applies to meson, the other popular modern build system. Meson also evolves and seems to like to deprecate old practices at a much faster pace than, say, GNU Make or some shell breaking compatibility (if at all). The more relevant danger for autotools builds is not the version of shell or make tool, but the compilers and C library getting more and more picky with updated standards and refusing actual code in the project. This is stressing enough for packagers. Build system version incompatibility adds on top of that. I liked waf, in principle, because it ships (did ship?) the tooling with the source package, like autotools, and only relies on a generic language interpreter — though the interpreter in this case being python, possibly prone to all the mess of python 2 vs 3.x vs 3.y. I am also ignorant about its features for cross-plattform support, building in MSVC etal. Alrighty then, Thomas -- Dr. Thomas Orgis HPC @ Universität Hamburg
