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? ;) [..] > 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. 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 for all platforms and build systems ;) > -- Ivan Zhakov
