Właśnie zaktualizowałem trochę starych paczek #Gentoo do EAPI 8. Niektóre nie były aktualizowane od 6 lat. I wiecie, co jest najlepsze? Że nadal działają — systemy budowania działają, kod się kompiluje, programy działają. W odróżnieniu od większości nowego oprogramowania.

#autotools #C

So I've just bumped a bunch of old #Gentoo packages to EAPI 8. Some of them haven't been updated for 6 years. And do you know what's best? They still worked — their build systems work, they compile and they just work. Unlike most of the stuff developed these days.

#autotools #C

#fvwm3 #autotools #meson #buildsystems

A little over six months ago, I said the following:

https://bsd.network/web/@thomasadam/113340194570527011

Since six months has passed, I've now pushed to `main` a PR which does just that -- removes autotools from #fvwm3 and replaces it with meson:

https://github.com/fvwmorg/fvwm3/pull/1191

So this has been your warning.

When I release fvwm3-1.1.3, it will be using meson only.

Any questions, please do let me know. I hope downstream packagers have made the transition. :)

I have a long-standing project which I am converting to use C++ modules. I've decided that using #perl to generate the Makefile is vastly easier than using #autotools and #cmake.

At least I can understand WTF is going on.

In the end, programmatical beats automagical.

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

Spotted on Reddit re #autotools: "It has more layers than an onion. It's enough to make a grown man cry. "

[Перевод] Параллельный ./configure

Извините, но в 2025 году — это просто смешно: $ time ./configure: 13.80s user 12.72s system 69% cpu 38.018 total

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

#autotools #configure #make #bash #automake #сборка #сборка_проекта

@jloc0

Indeed.

Aside from all of the other work going on, there is also a concerted effort to migrate from using #autotools to #meson for builds.

#Xfce

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.

say I need a build system for a project

such build system needs to be able to check if some libraries/features are available on the target OS

my project is written in an interpeted high level language but it calls some C libs

say I don't want to use the autotools

but I'd like my build system to be FLOSS

what are my options ?

#buildsystem
#Autotools

XZ Utils backdoor (CVE-2024-3094) 解説
https://qiita.com/naokiwa/items/203f558f5dd2a999b862?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items

#qiita #Linux #xz #sshd #autotools #lzma

So, if my goal is just to restore autotools happy-path of `./configure && make && make install` I need maybe ten lines of shell including the explainer blurb. If my goal is to create the best and universally-loved and appreciated one true CMake wrapper - a thing that is both normal to want and possible to achieve - then I need Python with custom `argparse.Action`s and some sort of reality-distortion field to avoid bike-shedding and yak-shaving.
#CMake #autotools

Autotools-skeuomorphic Makefile is super easy. Corresponding configure script still in progress; doing that in Python.
Then it finally occurred to me that one of the stumbling blocks is that autotools configure is stateless - it blows away the old configuration every time - where CMake keeps its configuration state and lets you mutate it incrementally. Now I need to wonder if my skeuomorphic configure script should blow away the build/binary directory each run…
#CMake #autotools

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 #длинная_арифметика #большие_числа

Got side-tracked on a project where step 1 is converting something from Autotools to Bazel. The lack of a sufficiently functional "make install" in Bazel is disappointing but not surprising, and I'll just live with that for now. Shell scripts won't save us, but they'll get us where we want to go until there's time to build something better. (Writing Starlark rules is not very fun.)

#autotools #make #bazel #rust #clang

That seems to be an issue in #lame project. The #autotools file configure.in does not find #ncurses with pkgconfig. Hence, it misses the required compiler flag for static linking. For that, -DNCURSES_STATIC flag has be manually added with CPPFLAGS or CFLAGS or CXXFLAGS variables.

https://github.com/msys2/MINGW-packages/issues/10312#issuecomment-1142448264

我在想，花在 #Autotools 上的碳排放是多少…一次 ./configure都能花五分钟……

If people just made a big deal about how much CO2 each run of #autotools make in a build we would've been rid of it by now, where's Greenpeace when you need them ​:satrithink:​

RE: https://is.badat.dev/objects/28c4786d-4d39-44a6-94b2-548b20dd4bcb

#fvwm3 #autotools #meson #muon #buildsystem

Hey all! Please note that although fvwm3-1.1.1 is close to being relesaed, there's still a few more things left to do.

Before that point, I'd like to take the opportunity to mention that as of fvwm3-1.1.1 fvwm3 is officially using meson/muon as the buildsystem of choice.

Autotools has been a tremendous help over the years. Heck, fvwm as a project started long before autotools existed.

But as technology changes, newer buildsystem alternatives have come along making better use of hardware, compilation speeds, etc.

Indeed, because of fvwm's age -- there's a tonne of custom m4 macros -- some of which are to work around issues long since gone. With autotools recently deprecating many of these, maintaining this was becoming difficult. Hence the change.

A six-month window exists once fvwm3-1.1.1 is released for downstream packagers to make the move from autotools to meson.

The `main` branch in the fvwm3 repository contains both buildsystems. Please give meson some testing!

A huge thanks goes to Kanjie (Matt Jolly) -- without whom none of this work would have been possible. Thanks, Matt!

For more specific details. please see: https://github.com/fvwmorg/fvwm3/discussions/1068

Questions? I'm here...

Me (being a smart ass): you know #autotools is an obsolete horrible mess of M4 and shell

> This works, because the ./dev.sh build command downloads all the major dependencies of #kitty as pre-built binaries for your platform and builds kitty to use these rather than system libraries.

Me (a humble version): that's worse somehow ... can I try to turn it off and on again?

#itcrowd