On 2. 6. 25 06:33, Branko Čibej wrote:
On 1. 6. 25 23:40, Timofei Zhakov wrote:
On Fri, 30 May 2025 at 4:44 PM, Branko Čibej <br...@apache.org> wrote:
Hi!
With the latest bunch of commits, I'm tentatively hopeful that the
CMake
build is now on par with the SCons build. But it needs a lot of
testing
and review.
One part where I'm a bit baffled is generating the pkg-config
file. The
more I look at it, the more it seems like the library list is
either too
long or incomplete, and the structure is inconsistent. It'd save
me a
lot of grief if someone more knowledgeable could have a look at
that...
I'm also unsure if we should generate a serf-config.cmake for
downstream
consumers, and where to install it if we do. CMake docs are less
than
specific, bit something like $prefix/lib/cmake/ or
$prefix/share/cmake
seems to be right for Unix, and just $preifx/cmake for Windows.
Anyway. I tested this on two platforms:
* arm64 macOS, with both Homebrew and MacPorts dependencies:
o with Homebrew, I used the default system zlib
o there is a system GSSAPI but if I use it, the tests go
into an
infinite loop
* arm64 Windows, using MSBuild (with Visual Studio) and vcpkg for
dependencies. Nothing very special there except that the
Windows VM
is horribly slow.
I didn't test with APR trunk (apr-2), perhaps I should. It's at
least
theoretically supported, and I'm sure it worked at one time, but
I'll
have to build that first.
So, any and all feedback welcome.
-- Brane
P.S.: No, I am *not* a CMake maestro. I keep a browser window with
cmake-3.12 docs open and that's pretty much it. I'm sure some things
could be done more modernly CMake-ish.
I remember when I tried cmake on my own, I didn’t really enjoy the
experience. It was working properly in general, but the thing is it
wasn’t felt finished. (Again, I’m talking about its state in the
past. I didn’t try it after your fixes.)
In my honest opinion, cmake scripts must contains as little custom
code as possible. I mean it should be written as intending by design,
keeping proper structure, and making it useful for users.
Sure I agree with all that.
Basically, as the most complicated part in the build system is
dependency search, they designed some sort of framework for that.
They made it so you can write a module in like a few commands. This
is how I made modules for apr and other libs in subversion. I’d like
to suggest (/ agree with you!) that we could merge those. In a recent
email to dev@s.a.o, you have mentioned that we should finish serf’s
one and use it in subversion. I would argue with that, because they
are done in a wrong way from what was intended.
Well I dunno, It pretty much works in almost any circumstances by now,
no matter what was "intended". Remember that this effort started
before there was a CMake 3, let alone 4; it was all 2.something, which
lacked a _lot_ of what you mention below. Rewriting the whole build
configuration every time the CMake guys think up a new way of doing
things, out with the old!, is really not something I'd like to spend
time on.
It's bad enough that SCons has backward-incompatible changes. Give me
autotools (without automake) any day, and also give me a big stick to
use on the monster who decided that it should all be written in m4 and
Bourne shell...
I guess, in subversion, we are missing few functionalities that serf
wants (pkgconfig search, apr-2 support, and emmm that’s it?). I think
we can simply implement those features in subversion and use the same
files in serf.
And stuff that Subversion doesn't use, like Brotli, OpenSSL, GSSAPI
(on not-Windows). Of those three, only OpenSSL ships a standar
Find*.cmake script with CMake.
On the other hand, serf is 1) incorrectly creates targets,
Please explain some more.
2) wants the root path to be passed manually, 3) weirdly executes
aprconfig (there is actually cmake module for that, which does it
automatically.
A CMake module for running apr-{1,2}-config and apu-1-config? Wow.
I have no idea why this wasn’t chosen initially), and 4) is little
messy.
The root dirs are required on Windows, not otherwise. If you use
dependencies from vcpkg, you don't need that -- but that's a vcpkg
thing, APR's CMake build is still experimental; although I see it
generates an apr-cmake-version.cmake file, at least on trunk. This is
relatively recent, older APR versions (that we still support) don't
have that. And anyway, that file is not installed on, e.g., Debian 12
with libapr1-dev (which is apr-1.7.2, so relatively recent).
Oh, and actually you can’t currently build serf without specifying
extra parameters for apr dir, which is quite confusing.
Which extra parameters?
That’s it… sorry if I’m wrong in any point. I’m open to discussing.
I'm happy to see any improvement in the CMake build, as long as it
still works and has all the features we need. :)
My goal was to make it work on pretty much all platforms in all
conceivable weird layouts of the modules, I didn't care too much about
"user-friendly". It's a build tool, not a phone app.
By the way, on Linux I just have to run: "cmake <source dir>", and it
just works, finding all the installed dependencies.
On macOS it's /almost/ there; which MacPorts and /opt/local/bin in the
PATH, it finds everything except the MacPorts zlib -- it takes the
system version, which is not so good because other MacPorts dependencies
use a different zlib. And since I have both Homebrew and MacPorts at the
moment, it picks some packages from each, pretty much guaranteeing
disaster. That's why I added USE_HOMEBREW and USE_MACPORTS options.
If we can make it work like that on Windows, that's cool. Maybe add
-DUSE_VCPKG=C:\vcpkg\some-magic-triplet\installed? I don't think there's
a sane way to guess the triplet. Ah, vcpkg probably has better support
for all that.
Yeah, back when I started porting Subversion to Windows, and/or building
Serf there, there was no vcpkg. Getting the dependencies was ... well,
let's say it was quite the adventure. I had to build *everything* from
source. If you've never tried to build OpenSSL 0.9 with its Perl-based
Makefile generator, you haven't lived yet. :D
-- Brane
