Live data from Hacker News

Using Make – writing less Makefile

text.causal.agency

111–120 of 200 posts

Re: Using Make – writing less Makefile

#111

Nice to see some love for make. Sure, make syntax sucks. It's arcane and hard to google much of what is going on. (Shower thought... a tool that lets you view a Makefile, giving explanatory tooltips for syntax elements would be great). But make is widespread, ancient and eternal. It isn't going anywhere, despite decades of new tools trying to take its place. It does many jobs relatively well. I'd go so far as to say…

> But make is widespread, ancient and eternal. It isn't going anywhere, despite decades of new tools trying to take its place. It does many jobs relatively well.

Agreed--make is eternal. One thing that'll probably be true: in a post-apocalyptic future, make will still be around and still be useful.

Re: Using Make – writing less Makefile

#112
post #79

This page just makes me miss manpages in general. Not every manpage was great, but many were, and many could also be formatted, printed out, and placed into a binder for easier reading. What I enjoyed most about manpages is that the people that cared to write good documentation on things like bash. If you have groff installed you can: man -Tpdf man >man.pdf The only problem with groff is that it doesn't support syste…

On recent vim, :Man crisply delivers within the same editor tab.

Re: Using Make – writing less Makefile

#113

I say this as someone with 20+ years of experience in C and C++: Using make is a huge waste of time in 2023 (and forward). Learning the intricacies of make actively blocks you from Getting Things Done. Yeah, make is kind of neat because it has this functional what_I_want : how_to_get_it syntax, but it doesn't actually work that way. It's a huge waste of time to try to get it working so unless you meet the following c…

3 paragraphs of rambling for "make is a waste of time because of sharp edges" Can you actually articulate what those sharp edges are?

yes, I can

Re: Using Make – writing less Makefile

#114
post #59

Earlier quoted context omitted.

I should rephrase, by dependencies I mean third party dependencies. That is on the build system not the compiler. And make tends to fall significantly behind Ninja in my experience for cold builds. Here’s a post from someone else that echoes my experience https://david.rothlis.net/ninja-benchmark/ but for a sufficiently complex project even a well tuned make build is about 20% slower on CI, which is about 10-20m per…

The link provided by you shows correctly that Ninja is indeed faster in the cases when almost nothing is recompiled, so the command execution time is dominated by the dependency evaluation time, which is faster in Ninja. However, the same link shows that even for relatively large projects the time difference is less than a second, which matches my experience. Ninja requires much more effort for using, as it is not a…

> GNU make does not need any such thing like the CMakeLists that are ubiquitous with CMake.

Then what is a Makefile?

And if your dependencies only amount to looking for source files, then that’s fine. Many are more complex than that and include configuration options themselves.

Again, I think you’re hyper indexing on just your own setup and ignoring anything outside of that, while simultaneously hand waving the number of bad makefiles out there and any shortcomings to drive home that Make is simplest.

Meanwhile by your posts, you’ve had to create an entire scaffolding of support around your makefiles to make it appear that simple. How is that any different than CMake or any other build system/generator? In the end you’ve just orchestrated your own version of such a thing and are decrying any other system as overly complex or just needing adjustments.

I believe we’re just talking past each other, but I’d really encourage you to consider that the reason you’re confused why people don’t just use Make is perhaps well founded and rooted in the number of things you have outright dismissed or don’t care about for your own projects. I’m not even specifically advocating for Cmake, but there’s no great mystery why so many projects use it or other build systems; it mostly lets them shift the responsibility of configuration to the system and focus on their task at hand. Again, exactly the same as C vs C++/Rust/etc…

Re: Using Make – writing less Makefile

#115

Earlier quoted context omitted.

Your coworker's experience is more principled: Make is a mediocre tool for executing commands. It wasn't ever designed for that. Although it is pretty common to see what you are mentioning in projects because it doesn't require installing a dependency. For a repo where an easy to install (single binary) dependency is a non-issue, consider using just. [1] You get `just -l` where you can see all the command available,…

With all due respect, I don't understand the first part of your comment. Make's core purpose is to execute commands, isn't it? How was it not designed to execute commands?

Out of the box with no configuration, Fish shell provides target completions for a Makefile in the current directory [1].

[1]: https://fishshell.com/docs/current/interactive.html

Re: Using Make – writing less Makefile

#116

Earlier quoted context omitted.

I prefer task over just, while I am not a huge fan of YAML, we now use it everywhere so it just makes sense to not learn yet another DSL for Just and just use YAML.

How do task and just compare to SCons? Although SCons is Python (which is a pro or con depending upon your perspective), it has strong dependency management. Or is the argument that dependency management is part of build, not general project maintenance?

Starting out from the blog post, it talks essentially about Make as it was intended, as a build system to compile programs with. Make maps this to the task of producing a file from input files, which are written down in the form of rules in a Makefile. a key ingredient from make is that it checks for timestamps on disk for the source files and updates targets only if the source files have been modified after the targets have been built.

If you go a bit further down this route, you end up with build tools that generate the compilation rules for you in some form: These are Automake/CMake/Meson and SCons. I did use scons years ago and it was nice, but its definitely completely lost its market share. IIRC Scons does this without generating Makefiles.

Task and Just are following a different route. The problem people have solved by using a "hack" in Makefiles (PHONY targets), so that you can easily run "sub-commands" in Make (make install_deps, etc). It would never occur to me to use Scons in that space.

Btw. a third option is to use a shell script like the following (POSIX-shell compatible actually).

  sub_install_deps() {
   set -e -x
   # ...
  }

  sc=$1
  case $sc in
  "" | "-h" | "--help")
   sub_help
   ;;
  *)
   shift
   "sub_${sc}" "$@"
   if [ $? = 127 ]; then
    echo "Error: '${sc}' is not a known sc." >&2
    echo "       Run '${prog_name} --help' for a list of known scs." >&2
    exit 1
   fi
   ;;
  esac

Re: Using Make – writing less Makefile

#117
post #103

Earlier quoted context omitted.

It's a poor, verbose, arcane solution in every problem space it purports to solve. It was fine in its era, but that's a long time ago. It is completely unsuitable as a project management tool and a poor task runner. Also its ubiquity is overhyped. There's no build platform where I can't download the tools I need, that's the entire point of a build platform, and most such platforms come with far more advanced tools pr…

Make has few dependencies so it's a way to build an operating system up from ground 0. Any tool/language that wishes to be generally useful in an OS doesn't want to be built by something that is only available much further up the tree like python. So it gets used a lot and it's only a language for dependencies and rules. It doesn't do "project management". Its the simplicity of what it's trying to that saves it from…

> Any tool/language that wishes to be generally useful in an OS doesn't want to be built by something that is only available much further up the tree like python.

This is a non-priority, an unreal use case. I can't build GCC without a functioning C++ compiler and a fairly sophisticated OS environment and that's fine. Real-world use cases for bootstrapping a build environment from rubbing two sticks together are so exceptionally rare as to be near fictional.

Even if we allow that such cases exist, they are unicorns, not a thing to design tools around.

> It's not a special tool for enforcing one structure or building only one language - something that seems highly regressive to me but which is adopted by many languages now.

This is what makes it so unsuitable. A tool that can make no assumptions about its application is less and less useful a tool. A bread knife is better at cutting bread than a plain 10" kitchen knife, a boning knife better for deboning, etc.

We live in a world where for every language there are build tools that know far, far more about the needs of that language environment than make, and thus are far better suited.

Re: Using Make – writing less Makefile

#118
post #87

Earlier quoted context omitted.

Ninja excludes a lot of features of make which are expensive to implement and cause it to be slower to parse so naturally in certain situations ninja runs faster than make. If your build time is actually affected by how long it takes to read the makefiles then this is important (e.g. building Android).

When the makefiles are well organized, all of them have just a few lines, with a few definitions, perhaps at most ten lines, but usually less, and they include a single bigger common Makefile, with most of the definitions, all the rules and all the make targets. So reading all the makefiles should take a negligible time, even in a big project. I have seen too many projects with huge makefiles and with much more makef…

Make does a lot more than just reading makefiles - sometimes it re-reads them as a result of something that happened in the makefile itself.

It's also doing a lot of variable expansion and if the makefile uses macros like define....endef to generate rules it has to expand those.

Make is also often trying all sorts of pattern rules to see if they will allow it to fulfill dependencies. This takes time.

If makefiles are small and you run make on each one separately then you miss dependencies across modules and you get the syndrome where program A doesn't get rebuild when library B changes.

So there's a price to pay for everything. Ninja is a lot faster because it just doesn't have some of these features and you can make a big makefile where dependencies work properly with it and not pay the price of slow parsing.

I worked on builds that took 12 hours on a large cluster of build machines where parsing was 45 minutes - so it matters. The more general solution would be to use a packaging system like the Linux distributions but even that doesn't save you from every problem as I also found out when working with OBS on a linux phone distribution.

Re: Using Make – writing less Makefile

#119

Nice to see some love for make. Sure, make syntax sucks. It's arcane and hard to google much of what is going on. (Shower thought... a tool that lets you view a Makefile, giving explanatory tooltips for syntax elements would be great). But make is widespread, ancient and eternal. It isn't going anywhere, despite decades of new tools trying to take its place. It does many jobs relatively well. I'd go so far as to say…

> the platonic ideal of development is: > make # Build the project > make install # Install the project > make clean # Clean the project build dir(s) IMO, that last step of cleaning is very not platonic ideal. However... maybe a reality of incremental development? The first step for me in a lot of cases is just trying a project to see if it's worth my time, typically that would just have been: cd /tmp git clone http:…

If nothing else, make clean is useful to recover disk space not needed anymore, which can be substantial. It’s like deleting a cache or a tmp directory. It can also help to fix the build process by resetting it if something got stuck in the wrong state, but that’s not necessarily the primary purpose.

Re: Using Make – writing less Makefile

#120
post #44

Earlier quoted context omitted.

That much is obvious given that a vanilla phone setup has no trouble with even 90-character lines. Not my business to stop anyone making things hard on themselves, though, so good luck you all! (do we have anyone who reads HN over a morse clacker?)

I have vision problems, I increase zoom a lot in desktop and mobile. What do you have against people different than youself?

Nothing; I wished you luck! I imagine people with screenreaders have an even tougher time...

(mobile I agree would be hopeless with zoom [I avoid reading on mine even without zoom], but does your desktop zoom mean even TFA's vt100-friendly 72-chars needed reflowing?)

Post reply on HN