4 ms·

> There is a huge population of us that smile and get things done, while others screw around with new, complicated, never-learned-the-past tools. They get the

> There is a huge population of us that smile and get things done, while others screw around with new, complicated, never-learned-the-past tools. They get the things done they've been doing all along. But build metadata is very important and very hard to extract from Makefiles, especially as builds increase in complexity. You need things like search paths accessible to get IDEs, static analyzers, software packaging systems, and other third party tools working with your code base. So make works great if the only things you're interested in doing are the top-level make commands you define, but it doesn't do you any favors when it comes to other things.

taeric 9y ago
Search paths accessible to other tools would have been just as well served standardizing search paths. Or, sadly, following standardized search paths. Instead, the new tools came and each one would buck any preceding trend and introduce a new way of doing things. Often poorly. All the while introducing yet another new way of executing the actual build. Let me preempt with saying that Make is not perfect. I genuinely feel that many things could have been improved on. However, I also question how many lessons learned in Make were carried forward, versus how many mistakes were just reintroduced and hit again and again.
Walf 9y ago
I don't understand your reasoning here. Make can call any program, and contain as many build targets as you would ever need. If some task can't be accomplished in Make itself or existing CLI programs, you write something that does that one task well, then ensure Make runs it whenever needed, even if that's every build.
- humanrebar 9y ago
  You could write make rules to do about anything, sure. But you don't want to have to rewrite those rules for every project. You want make modules that you can reuse from project to project. Those are notoriously hard to get right. And when they are done correctly, they are hard to share across organizations, or even within large organizations. In particular, I write a lot of C++. I want targets for gcov, g++, gtest, dpkg, rpm, clang-format, clang-tidy, cppcheck, clang, CLion, Eclipse, ctags, and include-what-you-use. Am I supposed to maintain each of those targets on each of my repos? It's simpler to have a standard place with all the needed source files, binaries, search paths, definitions, etc., and just wire that data up to each extra target.
  - Walf 9y ago
    Make's ability to include other makefiles is insufficient? Surely there's a relatively simple structure that would let you modularise tasks then include only the relevant ones per project.
  - Asooka 9y ago
    I also write C++ and am not aware how to comfortably automate all that with a single build tool. Is it some sort of cmake extensions? Can you please share your setup?
    - humanrebar 9y ago
      Some of those are built-in to cmake you can google "cmake clang-tidy" to find some examples, for instance. The rest can be added as custom targets and/or custom configuration options. The point is that you can write reusable cmake modules you can ship with your package manager or even git and a tweaked cmake search path. You can get there with make, but it's more work and a bit of a pain to replicate and maintain. In fact I often see teams with those setups put too many things in their repos to avoid build tool pain. Or, perhaps more often, they just give up on ever getting clang builds to work (for instance).

taeric 9y ago

Search paths accessible to other tools would have been just as well served standardizing search paths. Or, sadly, following standardized search paths. Instead, the new tools came and each one would buck any preceding trend and introduce a new way of doing things. Often poorly. All the while introducing yet another new way of executing the actual build. Let me preempt with saying that Make is not perfect. I genuinely feel that many things could have been improved on. However, I also question how many lessons learned in Make were carried forward, versus how many mistakes were just reintroduced and hit again and again.

Walf 9y ago

I don't understand your reasoning here. Make can call any program, and contain as many build targets as you would ever need. If some task can't be accomplished in Make itself or existing CLI programs, you write something that does that one task well, then ensure Make runs it whenever needed, even if that's every build.

humanrebar 9y ago
You could write make rules to do about anything, sure. But you don't want to have to rewrite those rules for every project. You want make modules that you can reuse from project to project. Those are notoriously hard to get right. And when they are done correctly, they are hard to share across organizations, or even within large organizations. In particular, I write a lot of C++. I want targets for gcov, g++, gtest, dpkg, rpm, clang-format, clang-tidy, cppcheck, clang, CLion, Eclipse, ctags, and include-what-you-use. Am I supposed to maintain each of those targets on each of my repos? It's simpler to have a standard place with all the needed source files, binaries, search paths, definitions, etc., and just wire that data up to each extra target.
- Walf 9y ago
  Make's ability to include other makefiles is insufficient? Surely there's a relatively simple structure that would let you modularise tasks then include only the relevant ones per project.
- Asooka 9y ago
  I also write C++ and am not aware how to comfortably automate all that with a single build tool. Is it some sort of cmake extensions? Can you please share your setup?
  - humanrebar 9y ago
    Some of those are built-in to cmake you can google "cmake clang-tidy" to find some examples, for instance. The rest can be added as custom targets and/or custom configuration options. The point is that you can write reusable cmake modules you can ship with your package manager or even git and a tweaked cmake search path. You can get there with make, but it's more work and a bit of a pain to replicate and maintain. In fact I often see teams with those setups put too many things in their repos to avoid build tool pain. Or, perhaps more often, they just give up on ever getting clang builds to work (for instance).