On 12. 5. 26 18:08, Timofei Zhakov wrote:
Hi all!
There are cmake configuration files in APR's upstream that were
primarily made to address complexity of building the project on
Windows platform and yet it's the only one supported.
I think it would be really cool to extend it to support all
platforms/configurations. There are however a few things that make it
complicated to implement;
1. Some platform specific code is put into dedicated subdirectories
(like file_io/unix/copy.c). But it's not exactly true because if you
look carefully you realise that the same copy.c is also used in
Windows build. This is not related that much to the build system, but
a general idea for the project, to put shared code away from */unix/.
I suggest moving those files under those subdirs into the parents of
unix/ (file_io/unix/copy.c -> file_io/copy.c), keeping only
platform specific code there. Also for example the os2 version of
copy.c simply includes the one for unix. So I believe this is
something that would be an improvement to keeping things organised.
I think it will be clearer when some ancient platforms are removed
from upstream...
I want to mention that, code from apr-util has this exact structure
because there is a little difference between platforms.
2. apr.h is a complete mess right now; There are four templates that
generate it and I believe some of them are outdated/unused. I want to
try to make the Unix and Windows versions to be as similar to each
other as possible. Perhaps we might rely on macros where different
code is needed. A lot of stuff is still similar, especially in the
modern days. The cmakefication will achieve that!
3. Some parts of cmake that we currently have are tied to Windows too
much. I think there is some refactoring to be done to get it to work
on Unix.
4. There are also some Unix specific features that are not fully
implemented in cmake currently.
I will be happy to try and extend cmake to work on Unix, if this
feature is wanted of course.
There are several real problems with CMake that make it hard to use in
any project with complex dependencies. I already mentioned the lack of
sane platform-specific defaults. For example, why does one have to
include(GNUInstallDirs) to get basic layout support and why did the
authors think this has anything to do with GNU when it's a POSIX thing?
One of the more painful and IMO malodorous problems is that it doesn't
have a full set of feature tests the way Autoconf does. It doesn't
differentiate between "symbol appears in a header", "symbol exists in a
library" and "you can actually link an executable with said library and
use that symbol". Just look at Serf's CMake build, we had to add our own
feature test functions to get those three different answers.
Another is of course the jumble of inconsistent FindPACKAGE modules with
their inconsistent outputs. Yes, you can use pkg-config but not all
dependencies ship .pc files and on top of that, the pkg-config support
just doesn't work on Windows even though vcpkg, for example, does
include .pc files with most of its packages.
TL;DR: supporting full-featured Unix builds with CMake would be a lot of
work, would probably make pretzels of the existing CMake build and would
duplicate what we already have in the perfectly good Autotools build.
What would *really* be cool is getting rid of apr.hwc and teaching CMake
to generate apr.h from apr.h.in. Imagine that, having a /single/ source
for our main platform-specific header! Could such a miracle be possible? 😏
-- Brane
