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.
-- Brane
