Re: CMake on Unix
Branko Čibej <[email protected]> Mon, 18 May 2026 16:13:04 +0200
| Newsgroups | gmane.comp.apache.apr.devel |
|---|---|
| Organization | The Apache Software Foundation |
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------Pmye4YxYWMy3XA0pt1yREbYT
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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
--------------Pmye4YxYWMy3XA0pt1yREbYT
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 12. 5. 26 18:08, Timofei Zhakov
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPD1kXSctD2m_=WKhv6wWebsS6oO67hQ33VP0B8dJqQjaOBzUg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hi all!</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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;</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>I think it will be clearer when some ancient platforms are
removed from upstream... </div>
<div><br>
</div>
<div>I want to mention that, code from apr-util has this exact
structure because there is a little difference between
platforms.</div>
<div><br>
</div>
<div>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!</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>4. There are also some Unix specific features that are not
fully implemented in cmake currently.</div>
<div><br>
</div>
<div>I will be happy to try and extend cmake to work on Unix, if
this feature is wanted of course.</div>
</div>
</blockquote>
<br>
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 <font face="monospace">include(GNUInstallDirs)</font> to
get basic layout support and why did the authors think this has
anything to do with GNU when it's a POSIX thing?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
What would <b>really</b> be cool is getting rid of <font
face="monospace">apr.hwc</font> and teaching CMake to generate <font
face="monospace">apr.h</font> from <font face="monospace">apr.h.in</font>.
Imagine that, having a <i>single</i> source for our main
platform-specific header! Could such a miracle be possible? 😏<br>
<br>
-- Brane<br>
<br>
<br>
</body>
</html>
--------------Pmye4YxYWMy3XA0pt1yREbYT--