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