I have started migrating macros from the Sorts Mill Autoconf Archive to a new archive, with improvements: https://github.com/chemoelectric/chemoelectric-autoconf-archive

Mostly the improvements are making the cache variables not have names that start with things like ‘________ac’.

#GNU #Autoconf #Autotools

i gotta say tho, as someone who spent the first ~15 years of my career doing web dev, going through the autotools docs was like exploring a museum. like a relic of the past

this c shit crazy

#autotools #c #automake #autoconf

It's been a while since I ran a build with #autoconf / #autotools. I had forgotten just how many different little things it checks for.

One of the main things it's checking for is whether certain headers and functions exist. That reminds me: #Rust `cfg` directives really ought to allow a predicate of “such-and-such function/type/whatever exists”. Then you can, for example, call a libc function that exists only on platforms that have it, with fallback on platforms that don't.

When building alsa-utils with a custom toolchain + sysroot, I get this error:

libtool: error: cannot find the library '/usr/lib/libasound.la' or unhandled argument '/usr/lib/libasound.la'

However, the file does exist inside of the sysroot, and configure claims to use the sysroot that the compiler specifies.

How do I solve this?

#Linux #LibTool #AutoMake #AutoConf #ALSA

LibMPU (создание проектов)

В предыдущей статье мы сделали краткий обзор возможностей библиотеки функций для работы с большими числами. В приведенных примерах, для автоматического задания флагов компилятора и компоновщика, мы рассмотрели использование скрипта mpu-config . Данный скрипт поставляется во время инсталляции LibMPU и позволяет упростить написание Make-файлов для программ, использующих библиотеку LibMPU . Однако это не единственный вариант составления Make-файлов с использованием данной библиотеки. В данной статье мы рассмотрим применение GNU Autotools , которые позволяют обеспечить переносимость программ и упростить создание сложных проектов. После инсталляции LibMPU на вашу GNU/Linux систему в распоряжении пользователя, помимо самой библиотеки, будет находиться m4-скрипт /usr/share/aclocal/libmpu.m4. Скрипт l ibmpu.m4 предназначен для использования в проектах, создаваемых с помошью утилит Autoconf , Automake .

https://habr.com/ru/articles/872332/

#gnu #autotools #autoconf #Automake #configure #длинная_арифметика #большие_числа

A wonderful history of early #GNU and much later by David MacKenzie -- who wrote many of the core utilities used today on all #GNU/#Linux systems, #GNU #Autoconf, and lots of other wonderful things. #FSF

https://www.youtube.com/watch?v=D7vfI-WSP8Q

#foss enthusiasts… Fancy a #gnu #autoconf #automake and #libtool #book? Swing by Hammersmith area and it’s yours. #macos #bsd #devops #books #development #developers #programming #oss #opensource #unix #linux

#autodafe 1.1 has been released (#autotools / #autoconf) https://gitlab.com/esr/autodafe

🎛️ What autoconf got right

https://leahneukirchen.org/blog/archive/2024/04/what-autoconf-got-right.html

#programming #softwaredevelopment #gnu #autoconf #tools #build

What #autoconf got right

https://leahneukirchen.org/blog/archive/2024/04/what-autoconf-got-right.html

Sure, but #Windows is still an Achilles Heal for the #AutoTools, unless you use #MinGW & #MSYS:

“What Autoconf Got Right”, Leah Neukirchen (https://leahneukirchen.org/blog/archive/2024/04/what-autoconf-got-right.html).

Via HN: https://news.ycombinator.com/item?id=40544336

On Lobsters: https://lobste.rs/s/ebnqzl/what_autoconf_got_right

#Unix #Autoconf #Build #Configure

Had to try to rescue a #Mikrotik today, connected to a (not-current) x86 Linux. Trying to build #MACTelnet for that system was unnecessarily complex: what's the point in using #autoconf if you insist that everyone must have the latest version of it, especially when nothing about your conf requires that version?

In the end I just had to remove the requirement for 2.71, take out a bunch of calls to htoleXX (easy because it's a le host anyway) and polyfill getrandom(), and it Just Works. 🤷‍♂️ </rant>

#GCC14 promoted some warnings to errors. This can break #autoconf, #CMake, #Meson or other build environments autoprobing for features, resulting in code built with missing or altered functionality. This could even lead to security impact, if some security related feature is unexpectedly not enabled.

Passing CC as "gcc -fpermissive" should fix this. If this is not an option there's even the nuclear option of adding a gcc wrapper script that does:

#!/bin/sh
exec /usr/bin/gcc -fpermissive "$@"

EDIT: I do not mean to say that these new options should blanket-disabled globally. There however are currently some packages that have problems with GCC 14 (missing features or existing functions not being used, or just failing to build). Naturally these packages should be fixed themselves. Meanwhile -fpermissive will allow building most of these troublesome packages.

People say #autoconf is incompatible with itself, but I just used autoconf 2.61 (!), an 18 year old(!!!) release, to generate a configure script for my project, for which I usually use autoconf 2.71.

Is the generated configure script identical? Of course not. Does the generated configure script work? Yes, without any buts!

So, if people are worried about shipping generated configure scripts due to what happened to #xz: Just don’t! Require the user to install autoconf and run ./autogen.sh before ./configure. The user doesn’t need to install a specific autoconf version if you write your configure.ac correctly.

Also, as for incompatible with itself: #CMake had several breaking changes in this timespan.

One of the sad side-effects of the #xz #backdoor is that many projects feel like they need to move away from #autoconf, when the problem wasn’t autoconf itself, but shipping a bunch of .m4 files – and that nobody diffed repo vs tarball (if nobody does that, it doesn’t matter what you do in the repo, e.g. switching build systems).

This is sad because it means cross-compiling stuff will soon no longer be possible, as autoconf is so far the only thing that gets cross-compiling right. CMake is a complete mess, Meson is far from great for cross-compiling and everything else just outright doesn’t support it.

People, clean up your configure.ac, get rid of .m4 and audit repo vs. tarball! That’s less work, much more effective and doesn’t kill cross-compiling!

Also, if you absolutely must blame a piece of software that was used by xz for this: That’ll be #gettext, which was the reason for the insane amount of .m4 files in the first place. gettext is a mess and that is really something we should get rid of.

"If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence

#autoconf

Regarding the #xz backdoor Jonathan Corbet from https://lwn.net/ thinks that #autoconf is part of the problem: "Why are we still using ancient build systems that almost nobody understands?"
So do I. I have not been using #sendmail for decades which used to have the same #m4 bullshit.

It's late enough to be hacker hours, if you're as old as I am. Gonna write down a bunch of rambly thoughts about #xz and #autoconf and capital-F Free Software sustainability and all that jazz. Plan is to edit it into a Proper Blog Post™ tomorrow. Rest of the thread will be unlisted but boosts and responses are encouraged.

Poll for the #autoconf haters:

You get to send *one* of the implementation languages to the cornfield. Which do you want gone more?