Re: CMake on Unix
Branko Čibej <[email protected]> Mon, 18 May 2026 17:22:39 +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. --------------JHaKV3Bm8UXmSyccUsK0qciq Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------JHaKV3Bm8UXmSyccUsK0qciq 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 18. 5. 26 17:04, Ivan Zhakov wrote:<br> </div> <blockquote type="cite" cite="mid:CAPZho0_4KetBWB9PpXUfwf5WhJjZh0E=Px-nS=GyZ40hAkHOsw@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <div dir="ltr"> <div dir="ltr"> <div dir="ltr">On Mon, 18 May 2026 at 16:13, Branko Čibej <<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> wrote:</div> <div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div> <div>On 12. 5. 26 18:08, Timofei Zhakov wrote:<br> </div> <blockquote type="cite"> <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> </div> </blockquote> <div>While I agree that CMake is very inconsistent. </div> <div>But at least CMake has GNUInstallDirs. I mean the same applies to autoconf: why it doesn't support Windows? ;) </div> </div> </div> </div> </blockquote> <br> But it does, if you use Cygwin or MSYS or WSL... :)<br> <br> 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.<br> <br> I still fondly remember when Microsoft released Microsoft C 6.0 and proudly presented ... 'nmake'! Almost but not quite entirely unlike 'make'...<br> <br> <br> <blockquote type="cite" cite="mid:CAPZho0_4KetBWB9PpXUfwf5WhJjZh0E=Px-nS=GyZ40hAkHOsw@mail.gmail.com"> <div dir="ltr"> <div dir="ltr"> <div class="gmail_quote"> <div><br> </div> <div>[..]</div> <div><br> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,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'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> </div> <blockquote class="gmail_quote" style="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> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div> 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"><a href="http://apr.h.in" target="_blank" moz-do-not-send="true">apr.h.in</a></font>. Imagine that, having a <i>single</i> source for our main platform-specific header! Could such a miracle be possible? 😏<br> <br> </div> </blockquote> <div> </div> <div>Well, I have started on working on this. I cleaned up apr.hnw and apr.hw. So we are close to have one <a href="http://apr.h.in" moz-do-not-send="true">apr.h.in</a> for all platforms and build systems ;)</div> </div> </div> </div> </blockquote> <br> I saw, and many many thanks for that!<br> <br> -- Brane<br> <br> </body> </html> --------------JHaKV3Bm8UXmSyccUsK0qciq--