• bignose@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    9 hours ago

    Give me a Make that

    • properly handles filenames with arbitrary names (Make today breaks if filenames contain whitespace)
    • uses space-based indentation level (Make today depends on the invisible difference between U+0008 TAB versus other whitespace, and refuses to process any other indentation)

    Give me that, and… well, I’d probably still stick to current-day Make, because those improvements would cause my Makefiles to be backward incompatible. Make is just reliably available on pretty much any arbitrary system, unlike any candidate replacement.

  • FizzyOrange@programming.dev
    link
    fedilink
    arrow-up
    4
    ·
    13 hours ago

    Yeah maybe, but usually if I’m using Make it’s because my use case is “I want users to be able to build stuff without having to install any more build tools”. The curse of network effects. That’s the only reason I’d ever use Bash too. Otherwise I’d switch to Nushell in a second.

    • plant@lemmy.stinky.rip
      link
      fedilink
      English
      arrow-up
      1
      ·
      13 hours ago

      I wish there were good alt-shells on Linux. Murex and Nushell are both still pretty nascent to actually use (not for portable scripts but just general day-to-day tasks) - and if it’s something you care about it’s annoying that Nushell is MIT-licensed instead of a free license, which kind of also precludes zsh.

      I genuinely kind of miss working a job that required using Windows because PowerShell is genuinely nice to use for throwaway tasks and working in a shell to do things like parsing json, fetching data from a http server, whatever.

  • hallettj@leminal.space
    link
    fedilink
    English
    arrow-up
    2
    ·
    18 hours ago

    There should be a universal build system that is declarative, handles interdependent build steps, skips building outputs that are still fresh, but that checks freshness in a way that’s more robust than tracking modification times, manages parallel execution intelligently, and that manages arbitrary external dependencies. Oh hey, it’s Nix!

  • Beej Jorgensen@lemmy.sdf.org
    link
    fedilink
    arrow-up
    1
    ·
    16 hours ago

    Make still bests the author’s examples in certain use cases. I use it all the time in those cases and it’s fast and simple. Use the right tool for the job.

  • username_1@discuss.tchncs.de
    link
    fedilink
    arrow-up
    12
    arrow-down
    1
    ·
    1 day ago

    We don’t have anything better, alas. All those build systems are crazy. Yes, CMake is crazy. And ugly. And inconvenient.

    • entwine@programming.dev
      link
      fedilink
      arrow-up
      5
      ·
      19 hours ago

      Yes, CMake is crazy. And ugly. And inconvenient

      How many years has it been since you last used CMake?

      CMake suffers from some of the same perception issues as C++. A lot of the criticism usually boils down to the designers prioritizing backwards compatibility, a thing even critics would agree is a good thing. As an example, the OP shows a CMake and Meson snippet. The CMake one is 3 lines, the Meson one is 2. The extra line in the CMake sample is a version declaration for backwards compatibility, but the rest are identical.

      If you look past your preconceived notions, you’ll find that CMake is a good build system and very easy to use. It’s also one of the few that fully supports C++20 modules today.

      It’s by no means a silver bullet, and the generator-based design isn’t always the best choice, but its undoubtedly the best choice for the vast majority of C or C++ projects.

      • fruitcantfly@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        18 hours ago

        Out of curiosity, why do you consider CMake to be the better choice compared to Meson?

        Personally I landed on Meson a few years ago, from what I remember chiefly due to simply not liking CMake’s DSL and finding Meson easier to work with, despite needing to target a pretty old version for the sake of compatibility. Though Meson is definitely not perfect either; it’s highly opinionated, and for example only recently got support for custom build targets putting stuff in sub-directories (as I discovered while writing this comment), so I’ll personally be stuck with my workarounds for a good while longer

        • entwine@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          18 hours ago

          I was never convinced by Meson’s value proposition. From what I remember, it was always just meant to reinvent CMake with a different DSL. Like, literally just CMake but slightly different.

          I understand CMake’s DSL isn’t the prettiest, but as far as improving ergonomics of a build system, minimizing the amount of build scripts you write is far more effective than changing the syntax. If you find yourself writing too much CMake in a project, then switching to a build system with a different design (eg Bazel, Scons, Waf, …) is probably the better choice.

          And of course, since Meson is just a CMake clone, it’s always going to be compared to it, and its always going to have to compete on features. On that front, CMake has always been ahead, and I don’t see that changing. So in the end, Meson is just another example of that one XKCD meme about standards.

          • fruitcantfly@programming.dev
            link
            fedilink
            arrow-up
            2
            ·
            15 hours ago

            Thank you for the answer!

            I have not previously heard Meson described as a reinvention of Cmake or a CMake clone, nor that it was meant to be. I would think that Meson being as opinionated as it is, including for example the fact that it does not and will not support user-defined functions, precludes it from being a CMake clone. It seems instead to be a build-system with a rather different philosophy and feature-set compared to Cmake. But if that philosophy or that feature-set does not match your needs, then there’s obviously no reason to pick it over CMake

  • onlinepersona@programming.dev
    link
    fedilink
    arrow-up
    12
    arrow-down
    5
    ·
    1 day ago

    I have convinced teams to switch to just after rewriting their makefiles in a fraction of the time and size. There have been some make die hards but they gave in to the team once they saw the justfiles.

    Luckily we didn’t have to write C or C++. I think the reason why that has so many build systems is because of the lack of a package manager. That entire world needs a cargo equivalent.

    • HelloRoot@lemy.lol
      link
      fedilink
      English
      arrow-up
      6
      ·
      edit-2
      1 day ago

      That entire world needs a cargo equivalent.

      The one time I needed to compile a rust app, I followed the instructions on their github and it used cargo and it didn’t work. Don’t remember the issue now, but it instantly gave me the same yuck I get when forced to use pip or npm and it breaks in the same fucking way.

      Had better luck compiling maven/gradle apps oh and yes, makefiles worked reliably for me so far.

      But this is just a personal anecdote and I rarely have to compile anything myself.

      • Denys Nykula@piefed.social
        link
        fedilink
        English
        arrow-up
        2
        ·
        16 hours ago

        What breaks with npm in your case? In my experience it’s been the rarest system to fail, like I can git clone something from 10 years ago, run npm i and the resulting app still builds and runs, despite a ton of announcements about deprecated libraries and update requests for vulnerability fixes.

    • [object Object]@lemmy.ca
      link
      fedilink
      arrow-up
      2
      ·
      21 hours ago

      For C/C++ make is a right tool for her job, but cmake is an improvement.

      I’m personally all in on nix these days for dev work

    • entwine@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      19 hours ago

      There are already plenty of package manager options in the C++ world. Having an “official” one arguably only helps improve the onboarding experience, but overall it’s a chokepoint for the entire ecosystem. There are rarely “one size fits all” solutions to a problem, and there certainly isn’t one for a problem as complex as software builds and packaging.

        • entwine@programming.dev
          link
          fedilink
          arrow-up
          3
          ·
          13 hours ago

          Conan and vcpkg are the two big ones I’m familiar with, but some projects use CMake FetchContent (with github acting as the CDN/registry), and depending on your requirements you can also just use system package managers on Linux, maybe Homebrew or Nix/Guix, or more niche ones like Spack. I’ve seen projects packaged using self hosted Pacman registries, and that works surprisingly well.

  • django@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 day ago

    There should be a tool recommender, which tells you the tool you’d want to use, depending on your preferences and use case.