On Wed, Jun 25, 2025 at 9:44 AM Daniel Sahlberg <daniel.l.sahlb...@gmail.com>
wrote:
> Den ons 25 juni 2025 kl 04:38 skrev Branko Čibej <br...@apache.org>:
>
> > On 23. 6. 25 03:27, Branko Čibej wrote:
> > > 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.
>
That. Right there. Rather than using a rando constructed "language", I
believe it makes more sense to use Python. And that means SCons.
Back in the day, people added functions to MATLIB. Then they added error
handling. Then they added ...
They tried to build a programming language into MATLIB.
But Python was already a programming language, and added packages for data
processing. It remained cohesive.
Guess which one is alive today?
> > 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.
>
Maybe. But that file needs testing and maintenance. Bugfix reporting and
support.
> > [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 think it is not a debate, to simply drop Py2 support. Anybody that wants
that, can perform the work themselves, or stick to an older Serf.
> > 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...
>
Heard. And agree. I'll get a couple builds tried. I only have Ubuntu
systems today, though.
>...
> 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?
>
Not yet ... I'd like a Python-based system, to handle our specific tests.
"We" know how to write Python code.
But points 4-6 are quite valid, so CMake can't be ruled out entirely.
We've been in this state before, and multiple build systems suck. The worst
part of this is where people in the community use different builds, and
(thus) are not helping each other with maintaining a simple build. Works
for one, not the other.
I haven't worked on Serf code for years. Not gonna try and hide that fact.
Yet I've seen the pain our project has been through, via multiple build
tools. That is why we picked SCons -- it handled all the platforms we cared
about. I honestly don't know why CMake was introduced. It kind of passed
by, and I didn't think of the implications until Brane's recent email. I
don't believe we can remain in a multi-build-system space.
Happy to help on this.
Cheers,
-g
