this post was submitted on 02 Nov 2024
45 points (97.9% liked)

Linux

48371 readers
1437 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

I had a teeny pet project using GNU assembly that was going to target two platforms.

Instead of keeping my handwritten worst-practices Makefile I decided to try GNU Autotools for the educated reasons of:

  • Text scrolling by looks pretty
  • Vague memories of ./configure make make install tarballs

I got hit with mysterious macro errors, recompile with -fPIE errors (didn't need this before?), autotools trying to run gcc on a .o file w/ the same options as an .s file, "no rule for all:", and other things a noob would run into. (I don't need a bugfix, since my handspun Makefile is "working on my machine" with uname -m.) So there's a bit of a learning curve here, inhibited by old documentation ~and~ ~more~ ~quietly,~ ~genAI~ ~being~ ~shittier~ ~than~ ~normal~ ~in~ ~this~ ~department~

With this I ask:

Do people still use Autotools for non-legacy stuff? If not, what do people choose for a new project's build system and why?

edit: trimmed an aside

top 14 comments
sorted by: hot top controversial new old
[–] Max_P@lemmy.max-p.me 21 points 3 weeks ago (1 children)

It's nicknamed the autohell tools for a reason.

It's neat but most of its functionality is completely useless to most people. The autotools are so old I think they even predate Linux itself, so it's designed for portability between UNIXes of the time, so it checks the compiler's capabilities and supported features and tries to find paths. That also wildly predate package managers, so they were the official way to install things so there was also a need to make sure to check for dependencies, find dependencies, and all that stuff. Nowadays you might as well just want to write a PKGBUILD if you want to install it, or a Dockerfile. Just no need to check for 99% of the stuff the autotools check. Everything it checks for has probably been standard compiler features for at least the last decade, and the package manager can ensure you have the build dependencies present.

Ultimately you eventually end up generating a Makefile via M4 macros through that whole process, so the Makefiles that get generated look as good as any other generated Makefiles from the likes of CMake and Meson. So you might as well just go for your hand written Makefile, and use a better tool when it's time to generate a Makefile.

(If only c++ build systems caught up to Golang lol)

At least it's not node_modules

[–] fool@programming.dev 10 points 3 weeks ago (1 children)

Wow, you're right, autotools dev work started a decade prior to Linux 0.01's release. And looking deeper into ./configure, there looks to be checks running here that only matter on old Solaris systems...

At least it's not node_modules

They call it a polyfill because it polyfills your disk

[–] ReversalHatchery@beehaw.org 5 points 3 weeks ago

They call it a polyfill because it polyfills your disk

nah, but storage is cheap bro, you really should just buy another hard drive! don't even think about going below 4 TB, of course!

/s

[–] algernon@lemmy.ml 16 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

Meson and CMake are the two major players I've seen along autotools. Are they better? In some respects, yes (especially Meson, imo), in others... not really. For a pet project that only targets two platforms, I'd just stick to handwritten worst-practices Makefile. You will likely have less trouble with that than any of the others, simply because you know it already.

[–] fool@programming.dev 2 points 3 weeks ago

Yeah I was considering using one of these two, out of curiosity.

I've heard complaints about CMake... on pre-2015 forums, so I don't know where it's at now.

I've done very little from the developer side of Meson but I do recall having tried a sound theme that, inexplicably, had a Meson-based installer. (It was just .ogg files iirc.) That's probably a good sign if someone picked it over an install.sh

Though you're right, there's probably little advantage in me not using a Makefile here, except again, curiosity

[–] Magister@lemmy.world 8 points 3 weeks ago

autoconf and stuff like this? Not anymore. Since ~5 years here it's cmake everywhere, Conan, ninja.

[–] 2xsaiko@discuss.tchncs.de 7 points 3 weeks ago (1 children)

Try Meson first, it should support compiling GNU assembly via the C compiler from what I can find. I've been using CMake for years because it is more powerful (finally trying out Meson though for a new project) but in contrary to Meson it is easy to use the wrong way if you don't know what you're doing. Meson is very clean in comparison, and also very easy to get started with. (And both these are absolutely better than autotools)

(If only c++ build systems caught up to Golang lol)

Terrible bait

[–] fool@programming.dev 3 points 3 weeks ago (1 children)

Terrible bait

Is that considered bait? I'll remove it, I don't mean to be hostile.

What do you mean by "more powerful" wrt CMake? Are you referring to, say, integration abilities with other projects (since know CMake is really widely-used)?

Thanks for the advice and the example!

[–] 2xsaiko@discuss.tchncs.de 8 points 3 weeks ago* (last edited 3 weeks ago)

What do you mean by “more powerful” wrt CMake?

CMake is a turing-complete language with some APIs that Meson either doesn't have an equivalent yet because it's comparatively new (for example, until 2023, there was no built in way to get a relative path from two paths, and if you wanted that you had to shell out to an external program), or they aren't going to add because it doesn't fit their design.

Meson is (intentionally) limited in terms of extensibility, instead it tries to come with everything built in that you need, even down to specific library support like Qt, from what it seems like to me. For example, you cannot define your own functions, it ships builtin modules but does not allow other packages to provide their own (for example like KDE's Extra CMake Modules), to name a few that I'm familiar with and why I was put off using it so far.

I have yet to see how actually limiting that is, going to try to move the project I've been working on for years that relies on some of these CMake features to Meson soon and see how it fares. But considering that big projects like GNOME use it all over the place it's probably workable in practice, I'll just have to rethink the existing approach a bit.

Is that considered bait?

Wasn't it? Go's build system is very much not what I would call an example of good design (exhibit A: load-bearing comments and file names).

[–] solrize@lemmy.world 5 points 3 weeks ago

I use autotools and don't remember having such issues.

[–] ardorhb@discuss.tchncs.de 3 points 3 weeks ago

I don't use autotools anymore for any of my private projects. It's plain Makefiles for me simple and easy. But I usualy only target Linux.

[–] eugenia@lemmy.ml 2 points 3 weeks ago

It doesn't matter if we "people use it in new projects", but rather, we often have to compile stuff that use them. So they need to be around, regardless of how bad they are. Just last week my husband had to compile two emulators that used autotools.

[–] serenissi@lemmy.world 2 points 3 weeks ago
[–] callcc@lemmy.world 2 points 3 weeks ago

Are you building a C/C++ project that should run on BSD, Gnu/Linux and other platforms? Then maybe use autotools. All distro tooling will easily be able to handle it.

Are you just building some small project that will never make it into a distro, maybe just use something simpler. Or even just a plain makefile.