<story><title>Future Plans for Autotools</title><url>https://lists.gnu.org/archive/html/autoconf/2021-01/msg00049.html</url></story><parent_chain><item><author>kstrauser</author><text>I wonder how much cruft could be thrown away if the project tossed out support for, say:&lt;p&gt;- Everything but Linux and a few of the more popular BSDs&lt;p&gt;- 32 bit CPUs&lt;p&gt;- CPUs with less than 1,000 installations&lt;p&gt;- Ancient toolsets that don&amp;#x27;t support features everyone else takes for granted in the last 20 years&lt;p&gt;For instance, it has to be a pain in the neck to sit on a code base with Solaris 2.6 support, or NetBSD on Alpha, or... Also, it seems like there&amp;#x27;d &lt;i&gt;have&lt;/i&gt; to be some legacy pain around things like &amp;quot;we can&amp;#x27;t use this flag on sed because Amix didn&amp;#x27;t have it&amp;quot;.&lt;p&gt;But I don&amp;#x27;t know enough about the infrastructure to know if pruning those out would make a bit of engineering difference. How much is support for ancient or little-used stuff slowing down development?&lt;p&gt;Edit:&lt;p&gt;Alternatively, I wonder what it would look like to have a build farm that precomputed all the values. &amp;quot;Oh, you&amp;#x27;re on macOS 11.1 on Intel? Here&amp;#x27;s the list of 32 envvars you need to set.&amp;quot; If a million people are compiling the same file on a million identical computers, is it a great idea for all of them to have run the same probes?&lt;p&gt;Edit 2:&lt;p&gt;I&amp;#x27;d never advocate for support for such systems to be scrubbed from the Internet. I&amp;#x27;m just saying it&amp;#x27;s unreasonable to &lt;i&gt;expect&lt;/i&gt; a maintainer today to support ancient systems. The people still using those systems have the right to fork the tools and maintain their own version, but that&amp;#x27;s not the same as making upstream do it for them.</text></item></parent_chain><comment><author>jerf</author><text>Per the discussion in the link, specifically &amp;quot;All the supported languages except C and C++ are second-class citizens.&amp;quot;, I&amp;#x27;d seriously consider writing off everything except C, C++, and any language where someone steps up to actively support their language going forward.&lt;p&gt;Slice autotools down to 32-bit &amp;amp; 64-bit UNIX systems in the last couple of years (bearing in mind that if you start that today, by the time it is finished it will constitute support for the last 3-5 years)... or even all the way to current systems for the parenthesized reason... for C and C++.&lt;p&gt;Would probably also call it &amp;quot;Autotools 3&amp;quot; and slice away anything else that doesn&amp;#x27;t seem useful, on the grounds that 2.7 isn&amp;#x27;t going anywhere. If in doubt, slice it away and see what people say when you release 2.99.01.&lt;p&gt;This probably takes it down to something not so enormous to carry around.&lt;p&gt;It seems like other languages are all going their own way. Maybe that&amp;#x27;s bad, maybe that&amp;#x27;s good, most likely it&amp;#x27;s a complicated combination of both, but most importantly, there&amp;#x27;s nothing Autotools can do to stop it at this point, so you might as well roll with it.</text></comment>
<story><title>Future Plans for Autotools</title><url>https://lists.gnu.org/archive/html/autoconf/2021-01/msg00049.html</url></story><parent_chain><item><author>kstrauser</author><text>I wonder how much cruft could be thrown away if the project tossed out support for, say:&lt;p&gt;- Everything but Linux and a few of the more popular BSDs&lt;p&gt;- 32 bit CPUs&lt;p&gt;- CPUs with less than 1,000 installations&lt;p&gt;- Ancient toolsets that don&amp;#x27;t support features everyone else takes for granted in the last 20 years&lt;p&gt;For instance, it has to be a pain in the neck to sit on a code base with Solaris 2.6 support, or NetBSD on Alpha, or... Also, it seems like there&amp;#x27;d &lt;i&gt;have&lt;/i&gt; to be some legacy pain around things like &amp;quot;we can&amp;#x27;t use this flag on sed because Amix didn&amp;#x27;t have it&amp;quot;.&lt;p&gt;But I don&amp;#x27;t know enough about the infrastructure to know if pruning those out would make a bit of engineering difference. How much is support for ancient or little-used stuff slowing down development?&lt;p&gt;Edit:&lt;p&gt;Alternatively, I wonder what it would look like to have a build farm that precomputed all the values. &amp;quot;Oh, you&amp;#x27;re on macOS 11.1 on Intel? Here&amp;#x27;s the list of 32 envvars you need to set.&amp;quot; If a million people are compiling the same file on a million identical computers, is it a great idea for all of them to have run the same probes?&lt;p&gt;Edit 2:&lt;p&gt;I&amp;#x27;d never advocate for support for such systems to be scrubbed from the Internet. I&amp;#x27;m just saying it&amp;#x27;s unreasonable to &lt;i&gt;expect&lt;/i&gt; a maintainer today to support ancient systems. The people still using those systems have the right to fork the tools and maintain their own version, but that&amp;#x27;s not the same as making upstream do it for them.</text></item></parent_chain><comment><author>yjftsjthsd-h</author><text>If you&amp;#x27;re going to cut off the long tail of compatibility, what&amp;#x27;s the point of using autotools? I thought the whole point of autotools was to deal with the (painful) diversity of operating systems.</text></comment>