Re: CMake on Unix

--000000000000695653065218e0f5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 18 May 2026 at 16:13, Branko =C4=8Cibej <[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. T=
he
> 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 an=
y
> 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 ju=
st
> 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? =
=F0=9F=98=8F
>
>
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 ;)

>
--=20
Ivan Zhakov

--000000000000695653065218e0f5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">On Mon, 18 May 2026 at 1=
6:13, Branko =C4=8Cibej &lt;<a href=3D"mailto:[email protected]" target=3D"_=
blank">[email protected]</a>&gt; wrote:</div><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

 =20
   =20
 =20
  <div>
    <div>On 12. 5. 26 18:08, Timofei Zhakov
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr">
        <div>Hi=C2=A0all!</div>
        <div><br>
        </div>
        <div>There are cmake configuration files in APR&#39;s upstream that
          were primarily=C2=A0made to address=C2=A0complexity of building t=
he
          project on Windows platform and yet it&#39;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&#39;s not
          exactly true because=C2=A0if you look carefully you realise
          that=C2=A0the 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 -&gt; file_io/copy.c),
          keeping only platform=C2=A0specific 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...=C2=A0</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=C2=A0mess 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=C2=A0possible. 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=C2=A0that!</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=3D"monospace">include(GNUInstallDirs)</font> to
    get basic layout support and why did the authors think this has
    anything to do with GNU when it&#39;s a POSIX thing?<br>
    <br></div></blockquote><div>While I agree that CMake is very inconsiste=
nt.=C2=A0</div><div>But at least CMake has=C2=A0GNUInstallDirs.=C2=A0 I mea=
n the same applies to autoconf: why it doesn&#39;t support Windows? ;)=C2=
=A0</div><div><br></div><div>[..]</div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div><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&#39;t work on Windows even though vcpkg, for example=
,
    does include .pc files with most of its packages.<br>
    <br></div></blockquote><div>+1. FindPackage() is the mess.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    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></div></blockquote><div>+1.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div>
    What would=C2=A0<b>really</b>=C2=A0be cool is getting rid of <font face=
=3D"monospace">apr.hwc</font> and teaching CMake to generate <font face=3D"=
monospace">apr.h</font> from <font face=3D"monospace"><a href=3D"http://apr=
.h.in" target=3D"_blank">apr.h.in</a></font>.
    Imagine that, having a=C2=A0<i>single</i>=C2=A0source for our main
    platform-specific header! Could such a miracle be possible? =F0=9F=98=
=8F<br>
    <br></div></blockquote><div>=C2=A0</div><div>Well, I have started on wo=
rking on this. I cleaned up apr.hnw and apr.hw. So we are close to have one=
 <a href=3D"http://apr.h.in">apr.h.in</a> for all platforms and build syste=
ms ;)</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

</blockquote></div><br><span class=3D"gmail_signature_prefix">-- </span><br=
><div dir=3D"ltr" class=3D"gmail_signature">Ivan Zhakov</div></div>
</div>

--000000000000695653065218e0f5--