3 ms·

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

by 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).

by Walf 9y ago

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).