Den ons 25 juni 2025 kl 04:38 skrev Branko Čibej <br...@apache.org>:
> On 23. 6. 25 03:27, Branko Čibej 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.
> >
>
>
> All that said, running the tests on Linux with a bit of debugging code
> added shows just how broken the SCons build currently is; this is what
> check.py prints if I tell it to look at LD_LIBRARY_PATH:
>
> LD_LIBRARY_PATH:
> '/usr/lib/aarch64-linux-gnu:$ZLIB/lib:$OPENSSL/lib:$BROTLI/lib:
> /usr/lib/aarch64-linux-gnu/mit-krb5'
>
>
> You could say that I'm not exactly thrilled. So anyone (including me)
> who'd rather see CMake go away really should step up and lend a hand.
> That's a not at all subtle hint...
>
> -- Brane
>
Sorry to hear about your pain with the build systems. I also saw the
"non-rebuild" issue in the SCons build system yesterday when reviewing
Graham's patch but I thought it was just me. But when I tried the CMake
build system I had trouble running the tests...
The thread summary so far as I understand it:
1. Both build systems have some issues, the build system documentation
could be better (in CMake it is non-existant).
2. It would be good to have one build system to focus resources.
3. Nathan asked for a few more days to study details.
4. It helps RedHat to have a CMake build system.
5. CMake is more "main stream" these days and it may be easier for
newcomers to get into building Serf.
6. I know Timofei has said previously (probably on the Subversion list)
that CMake is easier to work with on Windows - with full support directly
in Visual Studio.
7. We have seen improvements to both build systems over the last few weeks
- so we can't really declare either one "dead and not supported".
In my opinion it is not the time to deprecate/remove one of the build
systems. Primarily because, as Brane put it, it isn't like this causes a
critical remote root access exploit. But if the community would like to rip
one out, I'm leaning towards migrating away from SCons primarily because of
4-6 above (but like Nathan, I'd need to study details). Regarding 5, I
checked the Wikipedia page of SCons and of the approx 15 projects that were
listed there, at least 3 had migrated to CMake.
I'd suggest a few items that are up for grabs for interested parties:
- Improve the documentation (in particular when it comes to CMake).
- Figure out if there are any corner cases where CMake is not on par with
the SCons build system.
- Figure out if the issues Brane has recently uncovered in SCons can be
solved.
Have I missed something from the thread? Are we converging on some kind of
consensus?
Cheers,
Daniel
