I'd like to invite Joe Orton to the discussion, since I saw his name in the
SPEC file for Serf in Fedora 42.
Den mån 23 juni 2025 kl 03:27 skrev Branko Čibej <br...@apache.org>:
> On 10. 6. 25 08:24, Daniel Sahlberg wrote:
> > Den mån 9 juni 2025 kl 19:48 skrev Branko Čibej<br...@apache.org>:
> >
> >> On 9. 6. 25 19:20, Greg Stein wrote:
> >>> Branko,
> >>>
> >>> With all your recent work on the scons and cmake build systems, should
> we
> >>> throw one out?
> >>>
> >>> In the past, we had three separate build systems (iirc). One from
> >>> autotools, one custom .py script, and a Windows makefile or such. Then
> we
> >>> threw out all that junk and moved to SCons for all platforms, and our
> >>> custom bits simply became python code within scons.
> >>>
> >>> But it seems we are back to dual-maintenance of build systems (again).
> >>>
> >>> What is your [Branko] thinking on going with just one, or keeping both?
> >>>
> >>> Others: how do you think we should proceed? It feels like there is more
> >>> weight towards CMake over the past years.
> >>>
> >>> Personally, I like scons in that it uses python, so "we" know how to
> >> extend
> >>> it well for our needs. I don't know enough about CMake to judge it.
> >>>
> >>> Thoughts, people?
> >> This very question went through my mind earlier today, when I made SCons
> >> work on ARM64 Windows. And a couple days ago, when I installed Python 2
> >> and SCons 2.3.0 to verify that the build still works with our baseline
> >> versions. :)
> >>
> >> I like SCons, too. Our SConstruct is a bit of a mess in places, but
> >> that's our problem, not SCons'.
> >>
> >> I have a deep antipathy towards CMake. But in today's world where
> >> Windows development is basically becoming dependent on CMake, we can't
> >> ignore it. And since we do have a CMake build, it should work
> "everywhere".
> >>
> >> So it comes down to platform support. To build Serf with SCons, you need
> >> Python 2 and a compiler. Getting CMake to work is a bit more involved,
> >> unless it's Windows/Linux/*BSD.
> >>
> >> Do we care?
> >>
> > Thanks Greg for the look-back, most valuable!
> >
> > I'm not too fond of having multiple build systems because of the cost of
> > maintaining both and the risk of bitrot if one system starts lagging
> behind.
> >
> > There is also the issue of simplicity. When I first started looking at
> > Serf, I was confused trying to figure out how to build it, which build
> > system was better etc.
> >
> > Basically: it would be nice to have ONE tool to do the job GOOD than
> > multiple tools each with their own issues. (I have said the same in
> > Subversion and maybe also in APR).
> >
> > I'm not sure if we should care if it is possible to build using Python 2.
> > Chances are that any dependencies will not build anyway and then you
> might
> > be better off building an old version (which would support the old build
> > tools).
>
>
> The recent revelation that someone thought it was a good idea to take a
> build system that has a big, bold "EXPERIMENTAL!!" on the tin and use it
> in a rather popular Linux distribution, with the trivial side effect
> that the Serf package is now broken in a bunch of distros...
>
> ...has pretty much convinced me that adding a CMake build to Serf was a
> mistake that should be fixed sooner rather than later.
>
> No released version of Serf has a CMake build, so the question of
> backwards compatibility is moot.
>
> I therefore propose that we remove CMake support from Serf and
> concentrate on SCons instead. SCons is alive and well and stable[1] and
> is being actively developed. Windows dependents that use CMake can just
> go the pkg-config route to use Serf. Also, SCons isn't an exotic
> dependency: if you have Python, you can just `pip install scons`. That
> it's based on an actual programming language instead of the
> inconsistent, error-prone macro processor pile of ... sorry.
>
> The farthest I'd go to support CMake is to install a generated
> serf-config.cmake file. That's equivalent to providing serf-${MAJOR}.pc.
>
>
> -- Brane
>
> [1] Stable in the sense that SCons APIs that worked 10 years ago still
> work today in the same way. We now have a builder that uses Python 2
> with SCons 2.3.5 and just works. I would've never dreamed to attempt
> something like that with CMake.
>
I see the fact that Fedora was using CMake as a sign that there is a demand
for a CMake build system.
Some background:
The CMakeLists.txt in trunk was broken, in that it didn't contain the major
version. This was fixed in May 2025 [2].
RedHat[3] pulled the (broken) CMakeLists.txt from trunk and at least some
RedHat-derived distributions carry a libserf package with only the serf.pc
file. From [4] it seems at least Fedora 39-41 were affected.
Joe Orton changed the SPEC file in December 2024[4] to "provide both
libserv-1.pc and libserf.pc pkg-config files". That fix will obviously not
be needed anymore if they update to the latest CMakeLists.txt version (or
when we release something based on trunk), although they might decide to
still provide libserf.pc.
Maybe Joe can give us some more insight into RedHat's decision to use the
CMake build system - does it provide advantages for packagers?
There are clearly some developers here who are happy to work on the CMake
build system. I'd be happy to kick it out right away if we didn't have
anyone to work on it or if it provided an attack surface against Serf,
neither are true as far as I can tell. The only reason to kick it out would
be the "one tool to do the job and do it well" rule.
At the moment I don't see compelling evidence that we would gain something
at all by removing the CMake build system.
Cheers,
Daniel
[2]
https://svn.apache.org/viewvc/serf/trunk/CMakeLists.txt?r1=1925807&r2=1925911
[3] I have not checked who to blame here, and I don't think it matters. I
also have not checked what distributions/versions are affected apart from
Rocky9 but it seems likely that RHEL and probably some older Fedoras could
be affected.
[4]
https://src.fedoraproject.org/rpms/libserf/blob/rawhide/f/libserf.spec#_59
