When you type ./configure, the GNU Build System automatically spends the next ten minutes reminiscing about every major and minor unix variant created since 1971

@killerdicke @jordyd That's nice. I prefer configure systems that don't need to take ten minutes on *any* systems.

@vikxin @killerdicke @jordyd Is configure time even a real pain point, or is that one of those instances where we had to switch out the entire init system so servers could display a login prompt in under two seconds from the point the BIOS was finished with the three minute POST, and then load the actual services in the background when the person sitting in the datacenter frantically trying to log in wouldn't be bothered by that anymore?

@GyrosGeier @killerdicke @jordyd Whenever I update my kernel and dkms rebuilds ZFS it spends several minutes running all of the configure tests one at a time and then a few seconds actually building because of all the cores I have. Configure scripts are even worse on Windows where spinning up processes is slower. Autotools is bad and needs to go.

@vikxin @killerdicke @jordyd right, we could just assume that we're compiling on BSD, that would speed it up a lot. :>

@jordyd People who wonder why I hate autotools never seem to notice this.

@jordyd GNU autotools sighs wistfully for one machine whose sizeof(void*) was 5 for some reason

@BestGirlGrace @jordyd more software should be compiled on esoteric systems. These days I feel lucky if people use endian conversion macros for pointer values they write to PCI card registers rather than assuming that host and card have the same endianness.

For fun, I also built a big endian OpenCL target once, found a lot of bugs that way as well because suddenly, reading only the first half of a 64 bit value no longer gives the correct result.

@jordyd if only my distribution's maintainers had a way to tell the software running the toolchain packaged by my distribution's maintainers about the toolchain packaged by my distribution's maintainers

@bb010g @jordyd with my upstream author hat on: if only there was a way for my package to find the toolchain on any system.

Oh wait, there is.

@GyrosGeier @jordyd this would just be standardizing on a system-toolchain information file format, right? like a JSON file, telling you about quirks if it's present, and if it's not present the autoconf song-and-dance can generate one for you?

pkgconfig does this for libraries, instead of running detection on /usr/lib/.

@bb010g @jordyd the problem with any tool is that it needs to cover the existing use cases as well, or it is a regression. It was a long battle to get pkg-config to work with cross-compilation, and CMake's toolchain files are also a step backwards compared to interrogating the compiler, because now I have to predict what packages may look for, and provide the value by hand.

Maybe the other way round would be better: packages list values they need, and the configure tool checks If they are known

@jordyd sometimes it gets the details wrong if you actually ask it to remember though

@jordyd when time.h and sys/time.h could not be included together, when your Fortran was older than f77 even though you will only compile C anyhow, if your install is of a non-bsd flavor and if ar needs you to run ranlib before it. When default output filename could be something else than a.out and when you know you crosscompile by just failing to run a hello.c program.

I'll just hang my white computer operator coat over here.


Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!