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
