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

171–180 of 248 posts

Re: Why Use Make

#171

Post by _phred »

rachelbythebay wrote: post #74
falcolas wrote: post #35

Earlier quoted context omitted.

Lots of "Don't do this" without suggesting alternatives doesn't do anyone much good. If you're on a *nix system, building C/C++ programs (or automating one-off builds like the example), what would you recommend in make's place?

Assuming you're building your own code and are willing to arrange things in a compatible manner, then I have a solution to offer. It figures out the dependencies by reading the source code . You can create objects and binaries just by asking it to build a certain target. I recorded an example of installing and using it here: http://rachelbythebay.com/jvt/view?bb_install You can get a copy for experimentation here: ht…

Whoa, your terminal playback thing is pretty neat. Did you use GNU Screen to record the session?

Re: Why Use Make

#172

Post by McUsr »

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.

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 any of my users, installing something I have written.

Re: Why Use Make

#173

Post by queensnake »

Game_Ender wrote: post #143
eckzow wrote: post #96

Earlier quoted context omitted.

For Unix-only and smaller projects another great option is fabricate.py

Thanks for the tip on fabricate, it appears to be just the tool I was looking for. A light weight dependency based "build" system in python that is not focused on distutils or making python packages. We shall see how well it works for data processing.

'Drake' for that use was on here too, not too long ago. http://blog.factual.com/introducing-drake-a-kind-of-make-for...

Re: Why Use Make

#174

Post by jburnat »

mseebach wrote: post #26

Absolutely do not use make for any new project. If you love make, it's a big, red, burning flag that you're not demanding enough of your tools and that you're not keeping up with changes in your ecosystem. There are many, many way better alternatives to make. Which one is better depends on the platform you're on. The majority of them throws in automatic dependency management for free. Yes, I know that the essence of…

This is akin to saying that you should not be using libc, on account of there being many newer, more suitable libraries for string manipulation, I/O, and so on.

There's a clear downside to having dependencies on relatively obscure, cutting-edge technologies that may not necessarily work or be available elsewhere. And since build systems usually don't really need to be fancy, as much as they need to work, being conservative in this area usually doesn't hurt.

Re: Why Use Make

#175

Post by McUsr »

shadowmint wrote: post #160
Jare wrote: post #109

Earlier quoted context omitted.

> There are many, many way better alternatives to make. Which one is better depends on the platform you're on. There's your answer: there are many alternatives, but only one make. Ok maybe 2 o 4. :) But a build system should for the most part be platform agnostic. I have such a hard time understanding why so many programming languages seem to need their own Make alternative (Rake, Cake, Fake, ...?)

Sure, make is a generic tool, and you can do anything with it; from parsing json files, to compiling C code, to formatting documents. ...but so are bash scripts. I wouldn't advocate actually using either of these though, unless the situation is appropriate. Every system and platform has different requirements, and its a bit of a big ask to want make to be 'the right tool' for all of them. Certainly, I'd never use mak…

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

Re: Why Use Make

#176

Post by CmdrKrool »

ufo wrote: post #93
eropple wrote: post #9

Earlier quoted context omitted.

Personally, I don't want a programming language in my makefiles. Unless working in a very codified environment (Java and Maven, for example), I think it is vital to keep your build system as simple as you can. If I absolutely need nontrivial logic in my makefile, I would much, much rather be forced to call out to a script file (because it encourages not doing that ). And if you insist on parking a programming languag…

I hear this sort of argument all the time (build systems, templating engines, config files, etc) and I'm not sure I agree with it anymore. Invariably people start adding features and you wnd up with horrible warty languages full of corner cases like make or shell.

Yeah, limitations like these are often just a red rag to hackers that naturally love the challenge of overcoming apparent limitations with ornate workarounds. See the gmsl library mentioned in the current top post for example, which I read a bit of while trying to get a handle on the Android NDK's build system; respect to jgrahamc for its cleverness but if you don't like Make in the first place, you're inclined to feel that more of it is bad and not good.

Re: Why Use Make

#177

Post by CmdrKrool »

eckzow wrote: post #96
beagle3 wrote: post #77

Earlier quoted context omitted.

If you are on a unix system, "redo" (designed by djb and implemented by apenwarr) is excellent. It's refreshingly simple and robust. And, there's a minimalist version called "do" which is a hundred-or-so lines of shell, that does a complete rebuild (no dependency tracking) - so you can package that with your project, and not have to worry about your users having to install yet another build system. Other alternatives…

For Unix-only and smaller projects another great option is fabricate.py

Another vote for Fabricate; here's a comment of mine from a while back explaining in detail why I prefer it (or Tup) to Make.

http://news.ycombinator.com/item?id=4190804

I use it on Windows too with an strace replacement I wrote which isn't online but if anyone's interested then just ask.

Re: Why Use Make

#178

Post by sehugg »

tiziano88 wrote: post #115
sehugg wrote: post #90

I once used gmake to implement a multi-stage Mechanical Turk workflow. It was awful. The syntax sucks. But it worked consistently, and the core logic was only 110 lines of Makefile. It described the files and the data flow between them. Even now, I can read it and understand it with not too much effort. Make is a very simple functional language. It's restartable. If you type 'make -j 2' it becomes parallelizable. For…

actually, why not a shell script?

Shell scripts are fine, but if your shell scripts generate files than makefiles might help you model the dependencies between them. You get parallel execution and restart ability almost for free. (and they detect errors a little better)

Re: Why Use Make

#179

Post by rachelbythebay »

_phred wrote: post #171
rachelbythebay wrote: post #74

Earlier quoted context omitted.

Assuming you're building your own code and are willing to arrange things in a compatible manner, then I have a solution to offer. It figures out the dependencies by reading the source code . You can create objects and binaries just by asking it to build a certain target. I recorded an example of installing and using it here: http://rachelbythebay.com/jvt/view?bb_install You can get a copy for experimentation here: ht…

Whoa, your terminal playback thing is pretty neat. Did you use GNU Screen to record the session?

Thank you! I used script. Certain implementations have an option to emit timing and byte count data on stderr. Then it's just a matter of saving it and building something to honor those delays during playback.

Re: Why Use Make

#180

Post by __david__ »

ufo wrote: post #98
__david__ wrote: post #11

Earlier quoted context omitted.

After using Rake (ruby with some dependency DSLish stuff) on a project for a solid year, I appreciate Make much more. Rake is too powerful and makes it too easy to keep a bunch of complex logic inside the Rakefile. Our project, left unchecked, turned the Rakefile into a pile of spaghetti. Make, on the other hand, being kind of crufty and inconvenient, encourages moving complex logic out of itself and into external sc…

What sort of issue did you run into. I am wondering if its osmething that could be solved by better modularization/sandboxing or if its more fundamental problems.

It's not a programming issue per se, it's a human issue. Rake provides a nice baseline for throwing all your quickie scripts into little functions that end up with reasonable (if basic) command line interfaces for free.

Those quickie scripts inevitably grow more complicated as the project goes on (usually because the project itself gets more complicated over time) and before long you've outgrown Rake. Except that since Rake is just Ruby it tricks you into thinking you haven't outgrown it!

I started noticing it when I was taking a bunch of time deciding in what order I should be putting the optional parameters to my Rake tasks such that it was most convenient to the user and spending way to much code validating those arguments and setting defaults when I realized that I could've written a script using 'optparse' that would easier to document, easier to use, and easier to write and modify.

There's a graph you could make where the X axis is size of the script and the Y axis is complexity (or maybe "effort"). The Rake line, drawn on this graph, starts near 0,0 but climbs and a nice steep rate. Make starts at basically the same spot as Rake but climbs way faster. A standalone command-line script starts a bit higher on the Y axis, but is flatter over all. The point at which the Rake (or Make) and the script lines meet is where you should switch to a standalone script.

With Make, this happens fairly early on when things are still relatively simple. So you convert your bash commands into a Ruby script and you end up better off in the long run. With Rake it happens so late that converting to a standalone script becomes a very large undertaking and nobody wants to do it (because it still works--why mess with it?). Over the long haul it becomes a pain point.

Post reply on HN