<story><title>W64devkit: A Portable C and C++ Development Kit for Windows</title><url>https://nullprogram.com/blog/2020/05/15/</url></story><parent_chain><item><author>simfoo</author><text>&lt;i&gt;My unusual application of Docker here is no exception. Most software builds are needlessly complicated and fragile, especially Autoconf-based builds. Ironically, the worst configure scripts I’ve dealt with come from GNU projects. They waste time doing useless checks (“Does your compiler define size_t?”) then produce a build that doesn’t work anyway because you’re doing something slightly unusual. Worst of all, despite my best efforts, the build will be contaminated by the state of the system doing the build.&lt;/i&gt;&lt;p&gt;Completely agree, Autoconf needs to die. C++ builds don&amp;#x27;t &lt;i&gt;need&lt;/i&gt; to be complex and fragile, even if many environments are supported. Just use a minimal CMake build and resist the urge to implement &amp;quot;clever&amp;quot; things in it.</text></item></parent_chain><comment><author>radarsat1</author><text>If only CMake weren&amp;#x27;t just as awful.  It seems to have become an industry standard yet I can&amp;#x27;t begin to tell you how much time I&amp;#x27;ve wasted wrestling with it lately.  In an ideal world all projects would use CMake &amp;quot;correctly&amp;quot; but it&amp;#x27;s just not the case; problems are really hard to debug, no one really seems to know the current &amp;quot;right way&amp;quot; to do things, and the &amp;quot;right way&amp;quot; keeps changing anyway.&lt;p&gt;Coupled with an awful language, I just can&amp;#x27;t say that CMake is better, or much better, than autotools.  But at least it handles Visual Studio and ninja.  So yeah, we use it for the support it provides which is second-to-none, but it&amp;#x27;s a mostly terrible user experience, frankly.</text></comment>
<story><title>W64devkit: A Portable C and C++ Development Kit for Windows</title><url>https://nullprogram.com/blog/2020/05/15/</url></story><parent_chain><item><author>simfoo</author><text>&lt;i&gt;My unusual application of Docker here is no exception. Most software builds are needlessly complicated and fragile, especially Autoconf-based builds. Ironically, the worst configure scripts I’ve dealt with come from GNU projects. They waste time doing useless checks (“Does your compiler define size_t?”) then produce a build that doesn’t work anyway because you’re doing something slightly unusual. Worst of all, despite my best efforts, the build will be contaminated by the state of the system doing the build.&lt;/i&gt;&lt;p&gt;Completely agree, Autoconf needs to die. C++ builds don&amp;#x27;t &lt;i&gt;need&lt;/i&gt; to be complex and fragile, even if many environments are supported. Just use a minimal CMake build and resist the urge to implement &amp;quot;clever&amp;quot; things in it.</text></item></parent_chain><comment><author>pornel</author><text>If you do only minimal things, you will have fragile builds. The hacks are there not because people like adding complex code for no reason, but they&amp;#x27;re scars from broken builds.&lt;p&gt;For example, requirements for what has to be static and what dynamic are different on Linux (distros want unbundling) and macOS and Windows (you can link to handful of things that ship with the OS). macOS is especially annoying, because if you&amp;#x27;re not careful, you&amp;#x27;ll link dynamically to homebrew&amp;#x27;s non-permanent locations. `find_package` doesn&amp;#x27;t do the right thing without clever non-minimal things around it.</text></comment>