On 18. 5. 26 17:04, Ivan Zhakov wrote:
On Mon, 18 May 2026 at 16:13, Branko Čibej <[email protected]> wrote:
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?
While I agree that CMake is very inconsistent.
But at least CMake has GNUInstallDirs. I mean the same applies to
autoconf: why it doesn't support Windows? ;)
But it does, if you use Cygwin or MSYS or WSL... :)
More seriously, the real question is why doesn't Windows support
Autoconf. After all, Autoconf is older than Windows, though possibly not
older than DOS.
I still fondly remember when Microsoft released Microsoft C 6.0 and
proudly presented ... 'nmake'! Almost but not quite entirely unlike
'make'...
[..]
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.
+1. FindPackage() is the mess.
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.
+1.
What would *really* be cool is getting rid of apr.hwc and teaching
CMake to generate apr.h from apr.h.in <http://apr.h.in>. Imagine
that, having a /single/ source for our main platform-specific
header! Could such a miracle be possible? 😏
Well, I have started on working on this. I cleaned up apr.hnw and
apr.hw. So we are close to have one apr.h.in <http://apr.h.in> for all
platforms and build systems ;)
I saw, and many many thanks for that!
-- Brane
