Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Use Make

bost.ocks.org

Post reply on HN
Print view View original

201–210 of 248 posts

Re: Why Use Make

#201

Post by gchpaco »

shadowmint wrote: post #191
McUsr wrote: post #175

Earlier quoted context omitted.

I just want to inform you that GNU make indeed is very good for c projects as it can read the dependency files made by gcc (and clang), so you get very small very readable makefiles, that takes care of tracking the dependencies for you. http://wiki.osdev.org/Makefile

Really? There are a lot of people who use makefiles for C projects, but most of those people don't write them by hand. They use a frontend that generates a vastly complex and arcane makefile using either automake, cmake, qmake, etc. These makefiles are utterly unmaintainable and deserve a place next to 'goto' in the section labeled 'considered harmful'... but they serve a purpose; correctly collecting build settings,…

Linux kernel? Uses its own automation. See also *BSD make, which is the basis for ports among other things (unless that's changed since last I looked); entirely in-make. Plan 9 and the userspace port uses mk, which is a slightly cleaned up variant of the BSD make.

Fact is, a makefile for building C code is typically smaller than the autoconf files required to get autotools to work on the same code. Most horrible makefiles are written by terrible build automation software (autotools being among the worst offenders here) or by people who don't understand the dependency graph model. A ten line Makefile that automated something repetitive is fantastically important, even if it is just writing down something in an executable fashion such that you don't have to remember it later. Almost every build automation tool out there either doesn't scale up (too simple) or is too hard for small work, or occasionally both, like Ant.

If I need to do something simple, a Makefile is only a very little bit more complex than a command line—I frequently crib the command I just ran to start off the Makefile. If I needed to do nontrivial logic in a Makefile and couldn't avoid it, I wouldn't use jam or tup or redo or SCons—I couldn't, because they're less useful than make! I would probably end up using Rake, which is the only build automation tool I've seen so far that isn't a make clone and can do implicit dependency generation.

Re: Why Use Make

#202

Post by cdavid »

xymostech wrote: post #116
jahewson wrote: post #47

Earlier quoted context omitted.

CMake is an abomination

Mind pointing out any constructive arguments against it? I recently switched over from hand-built makefiles to cmake for one of my projects, and it's been a breeze.

Using a macro language was already bad in the 90ies (autoconf/automake using m4), but using one in 2000 is just tragic.

It is also impossible to debug, partly because of the abomination the cmake language is: even understanding where a variable is defined is hard, and because the language is so unexpressive, the Find*.cmake modules are often in the 1000s lines count.

For all its suckiness, I take autoconf/automake over cmake.

Re: Why Use Make

#203

Post by wyuenho »

jgrahamc wrote: post #17

If you use GNU Make it's worth using my GNU Make Standard Library: http://gmsl.sourceforge.net/ And also reading everything I wrote as Mr. Make: http://blog.jgc.org/2013/02/updated-list-of-my-gnu-make-arti... Or buy my book: http://www.lulu.com/shop/john-graham-cumming/gnu-make-unleas...

I haven't really used Make in any big projects (read: 100s of files and dependencies), but that's mainly because I have a habit of breaking components into smaller projects and thus keeping things, including my Makefiles, very simple. For project structures like that, I think your tools and book are overkill, so I'll recommend this reference from Oreilly's UNIX in a nutshell. I found that this is by far the most easily digestible reference for GNU Make I can find that's free. It's fairly to the point and concise as far as reference go, you can read the whole thing and have a fairly good understanding in under an hour. It's a reference that I go to 90% of the time, the other 10% come from Google and trial and error.

http://oreilly.com/linux/excerpts/9780596100292/gnu-make-uti...

Re: Why Use Make

#204

Post by narzac »

wildgift wrote: post #28

To everyone with alternatives to make: Make is easy to learn. It simplifies a slightly complex task. Other build tools have a steeper learning curve. If they're more complex than the problem being solved, people won't want to adopt them. When things get complex, there's the GNU make manual and libraries. When you have to target multiple platforms, there's autotools, which is really complex and intimidating, but less…

Definitely agree, unfortunately people always know better, even when they don't have any clue. My philosophy is "If the development environment provide you a modern, native build system(ex: go build, get), go with it, otherwise stick to make unless using autotools etc. will give you a reasonable advantage."

Re: Why Use Make

#205

Post by cpressey »

As noted in many of the comments, make sucks, and the article is not promoting make per se. But make seems to be the topic of conversation, so:

To me, make is a cruddy low-level declarative language that gets abused as a pseudo-imperative language, compounding the problem. Phony targets like "make " break the paradigm, because is not an artefact that can be tested for up-to-date-ness.

But one advantage of make that I'm seeing underrepresented in the comments is its ubiquity. If I just want to try your project, and I need to build your project to try it, and your project is using the cool new SchnauzerBuild[1] tool, and there's no SchnauzerBuild package for my OS, I have to go install that from source... which might have its own build dependencies... ok, your project looks kind of cool but I have better things to do than this.

I think it's great when build tools are able to write out a Makefile or sh[2] script that just builds everything, and when projects ship with that pregenerated. (and remember to keep it updated)

[1] fictional [2] another technology that sucks but is ubiquitous

Re: Why Use Make

#206

Post by [deleted] »

McUsr wrote: post #172
xymostech wrote: post #116

Earlier quoted context omitted.

Mind pointing out any constructive arguments against it? I recently switched over from hand-built makefiles to cmake for one of my projects, and it's been a breeze.

Yes, this is something I have thought through, though I may have been lucky/unlucky with my pick of projects. But generally speaking, installs I have installed based on GNU autotools, seems to install with less fuzz than those with C-Make. So, that, and the fact that there is full free documentation of GNU Autotools, even books out there, have made my personal choice easy. For me the overall factor is the ease for an…

[deleted]

Re: Why Use Make

#207

Post by [deleted] »

cdavid wrote: post #202
xymostech wrote: post #116

Earlier quoted context omitted.

Mind pointing out any constructive arguments against it? I recently switched over from hand-built makefiles to cmake for one of my projects, and it's been a breeze.

Using a macro language was already bad in the 90ies (autoconf/automake using m4), but using one in 2000 is just tragic. It is also impossible to debug, partly because of the abomination the cmake language is: even understanding where a variable is defined is hard, and because the language is so unexpressive, the Find*.cmake modules are often in the 1000s lines count. For all its suckiness, I take autoconf/automake ov…

[deleted]

Re: Why Use Make

#208

Post by Peaker »

quotemstr wrote: post #133
payload wrote: post #88

Earlier quoted context omitted.

Thanks for the links! I will definitely use tup for some next project. I try from time to time different make-like systems but I always come back to GNU Make. I also don't fear the GNU Make Reference. But tup looks, again, quite promising. It even has those little context sensitive one-special-char one-letter variables :) But they do something better by design, I see http://gittup.org/tup/make_vs_tup.html

> This page compares make to tup. This page is a little biased because tup is so fast. How fast? This one time a beam of light was flying through the vacuum of space at the speed of light and then tup went by and was like "Yo beam of light, you need a lift?" cuz tup was going so fast it thought the beam of light had a flat tire and was stuck. True story. Anyway, feel free to run your own comparisons if you don't beli…

You dislike his humor, that's fine. Calling it unprofessional is subjective. Some professional environments with great professional output appreciate humor.

Also, I am bottlenecked on my build system at my workplace, which takes ~45 seconds to realize nothing needs to be done (It isn't "make", because "make" does not support our build process).

Re: Why Use Make

#209

Post by dekken_ »

quotemstr wrote: post #132
malkia wrote: post #87

Earlier quoted context omitted.

Make is the assembly/C language of build system. Lots of other systems just generate makefile compatible files (qmake, cmake, premake, others), but often these fall into overly complex traps trying to explain everything both with simple unique words, and then clashing into these. Make is very optimal at the stage it is, everything above or below it it's just not that optimal.

> Make is very optimal at the stage it is, everything above or below it it's just not that optimal. Right: GNU Make is at a local optimum for describing how to generate products based on rules and a dependency graph. I'd also wager it's close to a global optimum. GNU Make is certainly closer to that global optimum than Boost's jam or the countless homegrown XML-based things I've seen over the years --- make is powerf…

Which "homegrown XML things"?

Re: Why Use Make

#210

Post by Peaker »

gyepi wrote: post #158
Peaker wrote: post #15

If your project sports auto-generated code, or any sort of build targets that depend on inputs only known after generation -- Make simply cannot handle this. There are ugly workarounds but they don't work well. Make is: * Slow (e.g: when compared with tup[1]) * Very easy to get it wrong (under-specify dependencies), with cryptic bugs (or over-building) as a result. Pretty difficult to get it right (e.g: doing proper…

> If your project sports auto-generated code, or any sort of > build targets that depend on inputs only known after > generation -- Make simply cannot handle this. > There are ugly workarounds but they don't work well. Hmm. I write a lot of generated code and have not found this to be true at all. Many of my projects have multiple levels of code generation that and make handles them just fine. The key is to play to m…

Can you should an example Makefile that does this correctly?

How do you get make to do a multi-phase build, that generates code, then scans it to add to the dependency tree, then generates more, and so forth?

Post reply on HN