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
inhttps://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
