|
|
Subscribe / Log in / New account

Rejuvenating Autoconf

Rejuvenating Autoconf

Posted Nov 3, 2020 17:20 UTC (Tue) by anton (subscriber, #25547)
In reply to: Rejuvenating Autoconf by marcH
Parent article: Rejuvenating Autoconf

With hindsight I think it's become clear that designing a language _without_ designing a companion build system was a mistake.
Given that many projects use multiple languages, designing build systems for a language is a mistake. E.g., automake is (or at least was, when we tried) useless for Gforth, because it does (did?) not offer anything for the non-C parts of Gforth, and was not worth the trouble for the C parts.

Anyway, this has nothing to do with autoconf, which is very useful for dealing with portability problems. It's great that it is being maintained.


to post comments

Rejuvenating Autoconf

Posted Nov 3, 2020 20:24 UTC (Tue) by marcH (subscriber, #57642) [Link] (1 responses)

In an ideal world yes it would be great to have a single polyglot build system that handles all programming languages. Of course it would not solve all linguistic problems, see GC discussion thread elsewhere on this page, but at least you would not have learn a new build system for each language.

In the real world you tend to only get build systems that "speak" a very small number of languages well... if any well at all. That's why most new languages come with some specialized build system. Admittedly sad but it lets them focus on providing more for their particular language. Also lets some of them not get distracted by "translation unit" conceptual limitations from the 70s or the utterly inconsistent mess of C toolchains.

Maybe some modular/plugin based architecture could do but good luck getting manpower for something like this - assuming it's even possible.

> Anyway, this has nothing to do with autoconf,

Apologies for being off-topic, I didn't realize other build systems had nothing to do with autoconf.

Rejuvenating Autoconf

Posted Nov 4, 2020 11:23 UTC (Wed) by anton (subscriber, #25547) [Link]

There is nothing language-specific about make or the basic functionality of autoconf. Autoconf comes with macros specific for shell, make, and C and C++ libraries, but you can also address other portability problems in this framework, e.g., whether m4 understands the "-s" flag, or how to skip 16 bytes of code space in assembly language (Gforth does both of this).


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds