You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@serf.apache.org by Timofei Zhakov <ti...@chemodax.net> on 2025/06/01 21:40:02 UTC
Re: CMake build status
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.
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.
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.
On the other hand, serf is 1) incorrectly creates targets, 2) wants the
root path to be passed manually, 3) weirdly executes aprconfig (there is
actually cmake module for that, which does it automatically. I have no idea
why this wasn’t chosen initially), and 4) is little messy.
Oh, and actually you can’t currently build serf without specifying extra
parameters for apr dir, which is quite confusing.
That’s it… sorry if I’m wrong in any point. I’m open to discussing.
>
Re: CMake build status
Posted by Branko Čibej <br...@apache.org>.
On 3. 6. 25 21:00, Timofei Zhakov wrote:
>
> >
> > Hi again,
> >
> > I've tested it. Here is my feedback.
> >
> > Both apr-1 and apr-2 works perfectly on a Unix environment.
> >
> > However, again, dependency search is done in the wrong way on
> Windows
> > and may work incorrectly in some cases. In cmake, find_library()
> > and find_path() are made so they handle all logic in relation to
> where
> > to look for each kind of artifact. They will handle system dirs,
> > -DCMAKE_INSTALL_DIR, -DCMAKE_PREFIX_PATH, <MODULENAME>_ROOT
> (APR_ROOT
> > in this case),
>
> Clearly, then, CMake's own FindOpenSSL.cmake is "doing it wrong",
> because it uses OPENSSL_ROOT_DIR instead of OpenSSL_ROOT... ;)
>
>
> I'm not sure, but I think they have changed it at some point and
> currently both of them are supported, but one of them is sort of
> "deprecated".
> Also they call find_path() passing several additional paths including
> one from the Windows Registry (which is quite weird),
Legacy. OpenSSL has a _long_ history of Windows ports, and I remember at
least two completely different ways to install it there. CMake/vcpkg is
a third. There was a time when it was "expected" that DLLs were somehow
registered, with configuration in the registry. I don't know the
details, but this is probably what they're doing.
> but don't prevent standard library search (as I explained with
> CMAKE_PREFIX_PATH and bla-bla-bla).
>
>
> > and even cmake's environment variables, and I guess vcpkg also
> > implements some custom things. This functionality is very useful
> for
> > people who need to set up their environments, to get builds against
> > right libraries etc...
>
> Ack
>
> > I would like to suggest fix with the
> serf-improve-apr-search.patch patch:
> >
> > [[[
> > cmake: Improve search of APR and APR-Util libraries by
> > calling find_library()
> > and find_path() methods without passing PATH, since cmake could
> > automatically
> > determine it based on platform-dependent factors.
> > ]]]
> >
> > After this patch, I got configuration successfully without
> modifying
> > settings on Windows which is good for now...
>
> Actually, your patch basically does on Windows what we do on other
> platforms, except that even there we handle *_ROOT ourselves. So it
> looks like we'd actually have to merge a lot of if(SERF_WINDOWS)
> branches into one generic search, which is good. I'll look into that
> when I have a moment.
>
> I'll just say that, when we first started writing CMakeLists.txt,
> find_package in CMake 2 didn't do half the things it does now.
>
>
> Oh, this makes sense...
>
> Thanks for the patch! It pointed me in the right direction.
>
>
> -- Brane
>
>
> Can we actually remove the warning that cmake is an
> experimental feature or not yet? I think as it is going to be
> released, it should not be just an experimental build system but a
> secondary one.
When we're actually satisfied with the way it works. Windows + Linux +
MacOS is 90+% of supported platforms, but there are others, oh yes;
where there might not even be a port of CMake. Also, right now,
SConstruct supports what we call "source layout" libraries, basically
where you built the dependency from sources and Serf would then just
look at the build tree, not the installed versions, to find the
libraries and headers.
This feature is probably irrelevant now that Windows is slowly, finally
joining the normal world when it comes to package management.
> I made an addition to the patch, because I forgot to do the same thing
> to locate the APR config executable. Updated patch is in the attachments.
>
> And I tested it on both Windows and Unix platforms (config and manual
> search).
>
> By the way, I think we should rework it a bit so we will try config
> first -- no matter whether the platform is unix like or not, and then,
> if pkgconfig or apr-1-config weren't found, try manual search instead
> (using find_path and find_library). because technically configs could
> be also available on windows.
APR doesn't install pkg-config files on Windows (neither does Serf), and
it may or may not install apr_config{_version}.cmake there; this could
be specific to the vcpkg port.
> For example, I think vcpkg does something in order to look for libs
> through pkgconfig on win32, so this is the case.
Sure, if it looks for that automatically, then yes. Last I looked you
have to load a module for pkg-config support. Anyway, I think I know
where we're going with this, and it'll be easier now that I can test on
Windows (and Linux ... where FindBrotli.cmake is not the same as
FindBROTLI.cmake) before comitting.
-- Brane
Re: CMake build status
Posted by Timofei Zhakov <ti...@chemodax.net>.
>
> >
> > Hi again,
> >
> > I've tested it. Here is my feedback.
> >
> > Both apr-1 and apr-2 works perfectly on a Unix environment.
> >
> > However, again, dependency search is done in the wrong way on Windows
> > and may work incorrectly in some cases. In cmake, find_library()
> > and find_path() are made so they handle all logic in relation to where
> > to look for each kind of artifact. They will handle system dirs,
> > -DCMAKE_INSTALL_DIR, -DCMAKE_PREFIX_PATH, <MODULENAME>_ROOT (APR_ROOT
> > in this case),
>
> Clearly, then, CMake's own FindOpenSSL.cmake is "doing it wrong",
> because it uses OPENSSL_ROOT_DIR instead of OpenSSL_ROOT... ;)
>
>
I'm not sure, but I think they have changed it at some point and currently
both of them are supported, but one of them is sort of "deprecated".
Also they call find_path() passing several additional paths including one
from the Windows Registry (which is quite weird), but don't prevent
standard library search (as I explained with CMAKE_PREFIX_PATH and
bla-bla-bla).
> > and even cmake's environment variables, and I guess vcpkg also
> > implements some custom things. This functionality is very useful for
> > people who need to set up their environments, to get builds against
> > right libraries etc...
>
> Ack
>
> > I would like to suggest fix with the serf-improve-apr-search.patch patch:
> >
> > [[[
> > cmake: Improve search of APR and APR-Util libraries by
> > calling find_library()
> > and find_path() methods without passing PATH, since cmake could
> > automatically
> > determine it based on platform-dependent factors.
> > ]]]
> >
> > After this patch, I got configuration successfully without modifying
> > settings on Windows which is good for now...
>
> Actually, your patch basically does on Windows what we do on other
> platforms, except that even there we handle *_ROOT ourselves. So it
> looks like we'd actually have to merge a lot of if(SERF_WINDOWS)
> branches into one generic search, which is good. I'll look into that
> when I have a moment.
>
> I'll just say that, when we first started writing CMakeLists.txt,
> find_package in CMake 2 didn't do half the things it does now.
>
Oh, this makes sense...
Thanks for the patch! It pointed me in the right direction.
> -- Brane
Can we actually remove the warning that cmake is an experimental feature or
not yet? I think as it is going to be released, it should not be just an
experimental build system but a secondary one.
I made an addition to the patch, because I forgot to do the same thing to
locate the APR config executable. Updated patch is in the attachments.
And I tested it on both Windows and Unix platforms (config and manual
search).
By the way, I think we should rework it a bit so we will try config first
-- no matter whether the platform is unix like or not, and then, if
pkgconfig or apr-1-config weren't found, try manual search instead (using
find_path and find_library). because technically configs could be also
available on windows. For example, I think vcpkg does something in order to
look for libs through pkgconfig on win32, so this is the case.
--
Timofei Zhakov
Re: CMake build status
Posted by Branko Čibej <br...@apache.org>.
On 3. 6. 25 14:05, Timofei Zhakov wrote:
> On Mon, Jun 2, 2025 at 7:04 AM Branko Čibej <br...@apache.org> wrote:
>
> 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
>
>
> Hi again,
>
> I've tested it. Here is my feedback.
>
> Both apr-1 and apr-2 works perfectly on a Unix environment.
>
> However, again, dependency search is done in the wrong way on Windows
> and may work incorrectly in some cases. In cmake, find_library()
> and find_path() are made so they handle all logic in relation to where
> to look for each kind of artifact. They will handle system dirs,
> -DCMAKE_INSTALL_DIR, -DCMAKE_PREFIX_PATH, <MODULENAME>_ROOT (APR_ROOT
> in this case),
Clearly, then, CMake's own FindOpenSSL.cmake is "doing it wrong",
because it uses OPENSSL_ROOT_DIR instead of OpenSSL_ROOT... ;)
> and even cmake's environment variables, and I guess vcpkg also
> implements some custom things. This functionality is very useful for
> people who need to set up their environments, to get builds against
> right libraries etc...
Ack
> I would like to suggest fix with the serf-improve-apr-search.patch patch:
>
> [[[
> cmake: Improve search of APR and APR-Util libraries by
> calling find_library()
> and find_path() methods without passing PATH, since cmake could
> automatically
> determine it based on platform-dependent factors.
> ]]]
>
> After this patch, I got configuration successfully without modifying
> settings on Windows which is good for now...
Actually, your patch basically does on Windows what we do on other
platforms, except that even there we handle *_ROOT ourselves. So it
looks like we'd actually have to merge a lot of if(SERF_WINDOWS)
branches into one generic search, which is good. I'll look into that
when I have a moment.
I'll just say that, when we first started writing CMakeLists.txt,
find_package in CMake 2 didn't do half the things it does now.
Thanks for the patch! It pointed me in the right direction.
-- Brane
Re: CMake build status
Posted by Timofei Zhakov <ti...@chemodax.net>.
On Mon, Jun 2, 2025 at 7:04 AM Branko Čibej <br...@apache.org> wrote:
> 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
Hi again,
I've tested it. Here is my feedback.
Both apr-1 and apr-2 works perfectly on a Unix environment.
However, again, dependency search is done in the wrong way on Windows and
may work incorrectly in some cases. In cmake, find_library()
and find_path() are made so they handle all logic in relation to where to
look for each kind of artifact. They will handle system dirs,
-DCMAKE_INSTALL_DIR, -DCMAKE_PREFIX_PATH, <MODULENAME>_ROOT (APR_ROOT in
this case), and even cmake's environment variables, and I guess vcpkg also
implements some custom things. This functionality is very useful for people
who need to set up their environments, to get builds against right
libraries etc...
I would like to suggest fix with the serf-improve-apr-search.patch patch:
[[[
cmake: Improve search of APR and APR-Util libraries by
calling find_library()
and find_path() methods without passing PATH, since cmake could
automatically
determine it based on platform-dependent factors.
]]]
After this patch, I got configuration successfully without modifying
settings on Windows which is good for now...
--
Timofei Zhakov
Re: CMake build status
Posted by Branko Čibej <br...@apache.org>.
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
Re: CMake build status
Posted by Branko Čibej <br...@apache.org>.
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