On Mon, 18 May 2026 at 17:22, Branko Čibej <[email protected]> wrote:
> 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 think we are both know that this question is more for historians, than for software engineers. May be because of bash? > I still fondly remember when Microsoft released Microsoft C 6.0 and > proudly presented ... 'nmake'! Almost but not quite entirely unlike > 'make'... > > Well, MS is well known for Embrace, Extend, and Extinguish behavior. I think with nmake that made two 'E' in one step ;) [..] -- Ivan Zhakov
