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

  • 2xsaiko@discuss.tchncs.de
    7·
    3 days ago

    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.devOP
      3·
      3 days ago

      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·
        3 days 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).