Build Tools – Make, no more

344 点作者 _superposition_大约 11 年前

36 条评论

vinkelhake大约 11 年前

I find these posts somewhat amusing. We've got people who (rightfully) question the tools they use and look for alternatives. They then discover Make and have some kind of zen Unix moment that they want to share with the world.If what you are doing in your flavor-of-the-month build tool translates to a roughly equivalent number of lines in Make, then yes, you should probably look at using Make. But the thing is, Make is stupid, it doesn't know a lot. Sometimes that is a good thing, sometimes it is not.I've written about this before on HN: I mostly program in C++ and when I build my stuff I want a build tool that understands things like header dependencies, optimization levels, shared libraries etc. It's a bonus if my build files are portable.My point is that these alternative tools often strive to raise the abstraction level and the reason people use them isn't necessarily because they haven't discovered Make.

评论 #7623775 未加载

评论 #7623866 未加载

Too大约 11 年前

Might go a bit off topic but i have to bring this up since 9 out of 10 make tutorials on the internet do the same horrific mistake as you just did, 11 out of 10 code bases out in the wild as well.In your make file example the .o files are just depending on the .cpp files, not the header files they include, the header files those included header files include and the files they include etc etc. This means nothing will be recompiled/relinked if a constant in a header file changes for example! Changed function signatures will give you cryptic linker errors with the standard solution "just try make clean first".To solve this you can either manually update the make file every time any file changes the files it includes, which almost defeats the purpose of having an automatic build system. Or you can use automatic dependency generation by invoking your compiler with a special flag (-MMD for GCC), and suddenly make isn't as simple anymore as you laid it out to be. In conclusion your build tool must be aware of ALL inclusion rules as your compiler(preprocessor) has, or be given the information somehow. Maybe it's better to just use something designed for your particular toolchain that can come bundled with this knowledge?

评论 #7623924 未加载

评论 #7625569 未加载

评论 #7624019 未加载

gyepi大约 11 年前

1. Since make has builtin suffix rules, the Makefile could be simplified to:<pre><code> CXX=g++ hello: main.o factorial.o hello.o clean: rm -rf *o hello </code></pre> 2. Shameless plug: he didn't mention redo [1], which is simpler than make and more reliable. The comparable redo scripts to the Makefile would be:<pre><code> cat <<EOF > @all.do redo hello EOF cat <<EOF > hello.do o='main.o factorial.o hello.o' redo-ifchange $o g++ $o -o $3 EOF cat <<EOF > default.o.do redo-ifchange $2.cpp g++ -c $1 -o $3 EOF cat <<EOF > @clean.do rm -rf *o hello EOF </code></pre> [Edit: Note that these are heredoc examples showing how to create the do scripts.]These are just shell scripts and can be extended as much as necesary. For instance, one can create a dependency on the compiler flags with these changes:<pre><code> cat <<EOF | install -m 0755 /dev/stdin cc #!/bin/sh g++ -c "\$@" EOF # sed -i 's/^$redo-ifchange.\+$/\1 cc/' *.do # sed -i 's}g++ -c}./cc}' *.do </code></pre> sed calls could be combined; separated here for readablility.[1] <a href="https://github.com/gyepisam/redux" rel="nofollow">https://github.com/gyepisam/redux</a>

评论 #7622468 未加载

评论 #7623504 未加载

评论 #7622486 未加载

评论 #7622937 未加载

tikhonj大约 11 年前

A build DSL solves the problem of making your build rules and systems first-class citizens. It's not just learning a new syntax—in fact, since you're embedding into a known language, it isn't even that new—it's about getting more control. You can pass rules around, modify them and do whatever arbitrarily complex tasks you need in a natural, straightforward way using your favorite programming language. You don't have to contort yourself and bend over backwards to fit the logic you want into Make's limited and peculiar language.Your build system is an integral part of your whole program and you want to treat it just like any other code. This means refactoring, this means modularity, this means libraries, this means no copying and pasting... All this is far easier with a system embedded in your main language than in Make. You can use your existing tooling, debuggers and frameworks to support your build system. If you're using a typed language, you can use the types to both constrain and guide your build files, making everything safer.Using an embedded DSL integrates far better with the rest of your ecosystem than relying on Make.Apart from making the logic of your build system easier to describe and maintain, an embedded DSL also makes arbitrary meta-tasks easier. You might want to monitor random parts of your build process, report to different services, connect to different front-ends (an IRC bot, a CI system...) and maybe even intelligently plug into the features of your main language. Wouldn't it be great to have a make system that's deeply aware of how your server is configured, how your type system works, what your compile-time metaprogramming is doing an so on?You could just glue together a bunch of disparate scripts with a Make file. Or you could use a DSL and call these services through well-defined, maybe even typed interfaces! No need for serializing and deserializing: you can keep everything inside your system.Sure, if you're just going to use your DSL as a different syntax for Make, you're not gaining much. But it allows you to do far more in a far better way, while fitting in more naturally with the rest of your code. I'm definitely all for it!

评论 #7625890 未加载

评论 #7625627 未加载

评论 #7624899 未加载

评论 #7626179 未加载

joeld42大约 11 年前

I think everyone goes through a phase where they try to find the perfect build tool, and then at least entertain the idea of writing one themselves.Eventually, you grow out of it. There's a lot of build tools, each are better at some things than others. It's not that much grunt work to convert things from one to another (even very large projects). If your build tool is working for you, leave it alone. If it's getting in your way or slowing things down, try another one. Move on.

BoppreH大约 11 年前

I think one reason is because Make is built with Shell, which is always one step (and one letter) away from hell.For example:<pre><code> clean: rm -rf *o hello </code></pre> Did you really mean to erase all files and directories that end in "o"? Let's say it's just a typo and fix it: "*.o".Now, are you sure it'll handle files with spaces in the name? What about dashes, brackets and asterisks? Accents? What if a directory ends in .o? Hidden files?This specific case may support all of the above. But if it doesn't, what will happen? How long until you notice, and how long still to diagnose the problem?Just like I prefer static strong typing when developing non-trivial projects, the build system should be more structured. I agree endless reinventing is tiring, but it may have some credit in this case.

评论 #7624810 未加载

ThePhysicist大约 11 年前

For me, the only justification for using a language-specific build tool (e.g. grunt, rake, paver, ...) is when you actually want to exchange data with a library / program written in that language. On the other hand, you could probably accomplish the same effect using environment variables, with the upside of having a cleaner interface.For those that are curious which build tools exist for Python, here's an (incomplete) list:* pyinvoke (<a href="https://github.com/pyinvoke" rel="nofollow">https://github.com/pyinvoke</a>) - claims to be the successor of fabric, pretty solid and well-maintained* fabric (<a href="http://www.fabfile.org/" rel="nofollow">http://www.fabfile.org/</a>) - not actually a build tool but often used as one* paver (<a href="http://paver.github.io/paver/" rel="nofollow">http://paver.github.io/paver/</a>) - no longer actively maintained* doit (<a href="http://pydoit.org/" rel="nofollow">http://pydoit.org/</a>) - one of the few tools that actually support monitoring file states (like the original make)* disttools (<a href="https://docs.python.org/2/distutils/" rel="nofollow">https://docs.python.org/2/distutils/</a>) - not actually a "universal" build tool but intended to distribute Python packages

评论 #7622841 未加载

rafekett大约 11 年前

the last 10 years in build tools has felt like 1 step forward, two steps back. i like being able to write tasks in any language other than Makefile. however, it seems like many of the new popular options (cake, grunt, etc.) don't do what, to me, is Make's real purpose: resolve dependencies and only rebuild what's necessary. new task runners have either eliminated or pigeonholed the (typically one-to-one in makeland) correspondence between tasks and files, meaning the build system can't be intelligent about what tasks to run and which to not.computers are fast enough that this doesn't often bother me anymore, but i've run across some huge Rakefiles that could benefit from a rewrite in Make.

评论 #7622645 未加载

评论 #7623952 未加载

评论 #7624680 未加载

评论 #7627971 未加载

flohofwoe大约 11 年前

Another vote for higher-level meta-build-systems like cmake, premake or scons (I'm using cmake because it has very simple cross-compilation support). My personal road to build-system nirwana looked like this, I'm sure this is fairly common:- Started using hand-written Makefiles and autoconf. Then someone wants to build on Windows, in Visual Studio nonetheless. Add manually created VStudio project files to the project. Then someone wants to use Xcode, so add manually created Xcode project files. Now you add files, or even need to change a compiler option. Fix the options in the Makefile, open the VisualStudio project, fix the options there, open the project in Xcode, fix the options there. Depending on the project complexity, this can take hours. The next guy needs to build the project in an older VisualStudio version, but the project files are not backward compatible...- Next step was to create my own "meta-build-system" in TCL (this was around 1999), which takes a simple descriptions of the project (what files to compile into what targets, and the dependencies between target), and creates Makefiles, VStudio-files and Xcode-files, this worked fine until the target project file formats change (happens with every new VisualStudio version).- Someone then pointed me to cmake which does exactly that but much better (creates Makefiles, VStudio-, Xcode-projects, etc... from a generic description of the sources, targets and their dependencies), and I'm a fairly happy cmake user since then.- Recently I started to wrap different cmake configuration (combinations of target platforms, build tools/IDE to use, and compile config (Release, Debug, etc...)) under a single python frontend script, since there can be dozens of those cmake configs for one project (target platforms: iOS, Android, OSX, Linux, Windows, emscripten, Google Native Client; build tools: make, ninja, Xcode, VStudio, Eclipse; compile configs: Debug, Release). But the frontend python script only calls cmake with the right options, nothing complicated.Of course now I'm sorta locked-in to cmake, and setting up a cmake-based build-system can be complex and challenging as well, but the result is an easy to maintain cross-platform build system which also supports IDEs.I general I'm having a lot less problems compiling cmake-based projects on my OSX and Windows machines then autoconf+Makefile-based projects.[edit: formatting]

评论 #7626955 未加载

asb大约 11 年前

I've recently been playing with ninja, which does a good job of not being 'just another make' <a href="http://martine.github.io/ninja/" rel="nofollow">http://martine.github.io/ninja/</a>. To quote their website, "Where other build systems are high-level languages Ninja aims to be an assembler.". It's used as a backend for GYP (Google Chromium) and is supported by CMake as well. I've had good success generating the files manually using something like ninja_syntax.py: <a href="https://github.com/martine/ninja/blob/master/misc/ninja_syntax.py" rel="nofollow">https://github.com/martine/ninja/blob/master/misc/ninja_synt...</a>.I also note that google are working on a successor to GYP, GN which targets Ninja <a href="http://code.google.com/p/chromium/wiki/gn" rel="nofollow">http://code.google.com/p/chromium/wiki/gn</a>.

评论 #7622896 未加载

luckydude大约 11 年前

I'm 52 years old. I've had this discussion with dmr, srk, maybe with wnj.All I know is for years, decades, I carried around the source to some simplistic make. I hate GNU make, I hate some of the unix makes. I loved the simple make.The beauty of make is it just spelled out what you needed to do. Every darn time make tried to get clever it just made it worse. It seemed like it would be better and then it was not.Make is the ultimate less is more. Just use it and be happy.

geuis大约 11 年前

Dunno if the owner of the site will read this, but here's a tip. Don't show a full screen overlay telling me how my visit would be better with cookies enabled.1) I have cookies enabled. 2) The Eurpoean law is daft, but since you feel you must comply do it in a more user friendly way.

评论 #7622729 未加载

评论 #7622122 未加载

评论 #7622195 未加载

msluyter大约 11 年前

Nothing against make, but I've found that it feels really nice when the majority of your toolset uses the same language. This is what I liked about Rails. Rails is ruby. Bundler is ruby. Rake is ruby. It's all ruby, which allows for a certain synergy, streamlined feel, and less cognitive overhead. I don't blame the js folks for attempting something similar.

评论 #7624412 未加载

apples2apples大约 11 年前

Misses the fundamental point that Make is broken for so many things. To begin with you have to have a single target for each file produced. Generating all the targets to get around this is a nightmare that results in unreadable debug messages and horribly unpredictable call paths.nix tried to solve much of this, but I agree it can't compete with the bazillion other options.

评论 #7622187 未加载

评论 #7622848 未加载

评论 #7622346 未加载

daemin大约 11 年前

I think the main problem with these articles is that the examples given are exceedingly simplistic, and hence in no way represent real world build systems. It's very easy to have a build system look nice and clean for trivial examples, when it breaks down is when the software it builds gets more complicated and the number of hacks and extra code is added making the build system into a big mess.

shoo大约 11 年前

I've been thinking a lot about build systems lately. I enjoy the discussion that this post has provoked. The post itself is weaker than it could have been, in that it does not stick to a single example when comparing build tools, and does not pin down any criteria for distinguishing between build tools.If you are interested in a comparison of a few interesting build tools, please check out Neil Mitchell's "build system shootout" : <a href="https://github.com/ndmitchell/build-shootout" rel="nofollow">https://github.com/ndmitchell/build-shootout</a> . Neil is the author of the `Shake` build system. The shootout compares `Make`, `Ninja`, `Shake`, `tup` and `fabricate`.Another possibly interesting build tool is `buck`, although it is primarily aimed at java / android development. See <a href="http://facebook.github.io/buck/" rel="nofollow">http://facebook.github.io/buck/</a> . There's a little discussion about `gerrit`'s move to `buck` here: <a href="http://www.infoq.com/news/2013/10/gerrit-buck" rel="nofollow">http://www.infoq.com/news/2013/10/gerrit-buck</a> .Here's some questions I'd ask of a build system:- is it mature?- which platforms does it support?- which language ecosystems does it support? (language-agnostic? C/C++? ruby? python? java?)- does it support parallel builds?- does it support incremental builds?- are incremental builds accurate?- is it primarily file-based?- how does it decide when build targets are up-to-date, if at all? (e.g. timestamps, md5 hash of content, notification from the operating system)- does it allow build scripts for different components to be defined across multiple files and handled during the same build?- does it enforce a particular structure upon your build scripts that makes them more maintainable?- how does it automatically discover dependencies, if at all? (e.g. parsing source files, asking the compiler, builds instrumented via FUSE/strace)- how easy is it to debug?- is it possible to extend in a full-featured programming language?- does it let you augment the build dependency graph mid-way through execution of a build?- how simply can it be used with other tools such as your chosen continuous integration server, test framework(s), build artifact caches, etc?Many of these criteria are completely overkill for trivial build tasks, where you don't really need anything fancy.

sheetjs大约 11 年前

One big advantage of vanilla Make is the community. There are some very nice tools that work well with make (such as <a href="https://github.com/mbostock/smash" rel="nofollow">https://github.com/mbostock/smash</a>).

评论 #7622509 未加载

drawkbox大约 11 年前

At least we are moving the direction of Grunt/Gulp rather than a maven sort of direction. Many lives lost to maven, somewhat of a Vietnam of build tools. You might think you are a Java developer with it but truly you are a maven servant.

Xorlev大约 11 年前

This post rather misses that while Make is simple, making Make do all the things we're used to (e.g. Java dependency management) not as simple.I'd like to think people have decided that it's easier to replicate the task part of Makefiles onto their environment as the simpler alternative to making dependency management and various other language-specific tasks available to make.

Zelphyr大约 11 年前

Never underestimate a young developer's need to reinvent reinventing the wheel.

malkia大约 11 年前

Make is the "assembly" language for build systems. Qt's qmake/cmake target it, and the output produced is horrible, but then using "make -j8" or qt's own "jom.exe -j8" as replacement for the underperforming nmake.exe and you are all set.

arrowgunz大约 11 年前

Make is still the best build tool form me.<a href="https://algorithms.rdio.com/post/make/" rel="nofollow">https://algorithms.rdio.com/post/make/</a>

josephschmoe大约 11 年前

I've never felt hindered by Gradle.Hindered by the fact I can't add an arbitrary github repo through Gradle? Yes. That seems like it should be solvable though...

评论 #7624531 未加载

demallien大约 11 年前

Heh. The one and only time that I ever wrote a parser in my professional career was for a build tool. In my defence, at the time I didn't know much about command line tools, and had only really programmed in IDEs. So when the new project was to be compiled on the command line, I quickly discovered that maintaining dependencies, changing targets and doing all the other things that a build system generally does by hand quickly gets old. Not knowing that autotools, cmake, ant, and about a bajillion other tools already existed to do just this, I wrote my own language, with a parser in ruby, no less :DI have since repented. I find autotools (with occasionally a script of [ruby|python|perl] to handle something that would otherwise be tricky to do in make or m4, which is then called by the makefile) works a treat. Just don't try to do anything tricky in the auto tool files - as I said, boot anything exotic out to a separate tool.Also, any discussion of build tools without also discussing package management is but half a discussion.

eponeponepon大约 11 年前

I'm unreasonably fond of Ant - there's plenty of scope for pointless clever-dickery, and there are days where that's all that keeps me going!Nice to see it mentioned in a context other than "oh god what a mess"... even though, in fairness, many aspects of it are a complete dog's dinner.

评论 #7622478 未加载

krick大约 11 年前

In fact I agree. I would be really glad if somebody explained me persuasively which one build-tools is the best one ever, so I could use it always and for everything, even when a shell-script would be enough. Yeah, it would be nice. But then, don't we have the same thing with about every class of software? Tens of text-editors and no perfect one. Many OSes and nothing sane. So many programming languages with overlapping functionality! And we won't even talk about such thing as linux distributions (and their packaging tools), pepsi&coca-cola… oh, it's not even software.So, yeah, there are too many build-tools. Whatever.

anonymous85大约 11 年前

I hate how far spread apart the JS community is but I'm excited for the day it starts to all come together and we don't have to worry about Javascript stacks becoming outdated within 6 months

pwenzel大约 11 年前

I appreciate Grunt and Gulp, but still fall back to Make for many of my web projects, even those that require a CSS or Javascript build system.Here's a Makefile example that utilizes fswatch: <a href="http://blogs.mpr.org/developer/2014/02/makefile/" rel="nofollow">http://blogs.mpr.org/developer/2014/02/makefile/</a>

nightcracker大约 11 年前

I'm currently working on a build tool that doesn't work using the traditional "makefile" approach. Instead it's designed as a Python library, and you have the full power of Python at your disposal.Sadly it's not ready for prime-time yet (early designing stage), so I won't link my highly unfinished project.

评论 #7622344 未加载

评论 #7622345 未加载

评论 #7623573 未加载

mwcampbell大约 11 年前

Rich Felker, the lead developer of musl libc, uses make to generate his ewontfix.com blog. See <a href="http://ewontfix.com/Makefile" rel="nofollow">http://ewontfix.com/Makefile</a>

评论 #7624808 未加载

ASneakyFox大约 11 年前

I get redirected with. "Your experience on this site will be enhanced by allowing cookies"I need cookies to read a blog post? Don't think so. Probably not worth the read

评论 #7624170 未加载

runarberg大约 11 年前

What about having your text editor do the build for you (use `.dir-locals.el` in emacs to compile your less on save for example)

Kiro大约 11 年前

Why would you need Grunt just to compile LESS?

评论 #7622321 未加载

mamcx大约 11 年前

I start using <a href="https://github.com/rags/pynt" rel="nofollow">https://github.com/rags/pynt</a>, and what a change. Is the simples thing you can imagine. Combining with request and <a href="http://plumbum.readthedocs.org/en/latest/" rel="nofollow">http://plumbum.readthedocs.org/en/latest/</a> (or similar) and whoila, you are done.

mutert2大约 11 年前

What about contribution packages of Grunt/Gulp?

SchizoDuckie大约 11 年前

So he's saying use 'make' instead of gulp/grunt and then he submits an example where it's as easy as piping through GCC.He's making the wrong assumption that you don't need to setup a build environment when building with make, but to have gcc you will still also need to install g++ and build-tools. Also, he refers to building on Windows using yet another specialist tool, but have you recently tried building anything C++ on Windows when you don't have visual studio, or even worse, CYGWIN installed?When you make such a statement, then please show me a makefile that's not 10.000 lines long, that will do the same as this, but without NPM and 'downloading half of the internet'.<pre><code> gulp.task('scripts', function() { // Minify and copy all JavaScript (except vendor scripts) return gulp.src(paths.scripts) .pipe(coffee()) .pipe(uglify()) .pipe(concat('all.min.js')) .pipe(gulp.dest('build/js')); }); </code></pre> I submit that's impossible, simply because this stuff took 2 years to evolve (for the Javascript toolchain, that is) and a lot of people went through hours of frustration trying out alternative methods.

评论 #7622371 未加载

评论 #7622466 未加载

评论 #7624372 未加载

评论 #7622479 未加载

评论 #7622338 未加载

评论 #7622337 未加载

评论 #7622404 未加载

评论 #7624452 未加载