Holy crap. I didn't realize the spread of broken. ... Yeah, I thought it
was "we're trying".
Short of a veto, I concur with removing CMake entirely from the serf build
options. It is something that matters to me, and happy to help.
72 hours, starting now.
Cheers,
-g
On Sun, Jun 22, 2025 at 8:27 PM Branko Čibej <br...@apache.org> wrote:
> 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.
>
