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

241–248 of 248 posts

Re: Why Use Make

#241

Post by lmm »

elteto wrote: post #76
niggler wrote: post #39

Earlier quoted context omitted.

"There are many, many way better alternatives to make" Can you give an example with the ubiquity of make and better expressiveness?

For OP's particular use case... bash? More expressive and a standard on pretty much all *nix systems.

Indeed. The metric is exactly wrong; you don't want a more expressive alternative to make, you want a less expressive alternative - one in which builds are more constrained, so that a newcomer to your project has a chance of figuring out what's actually going on.

Re: Why Use Make

#242

Post by chubot »

mshal wrote: post #225
Peaker wrote: post #84

Earlier quoted context omitted.

Yeah, though it is not that horrible since tup allows you to over-specify dependencies with very minor ill-effects (less parallelism, but no over-building). My list of short-comings besides that are: * No "run" command on Windows, means if you want portable tup you're stuck with its primitive scripting language (or reverting to Make-style hacks like ugly multi-phase build that generates the Tupfiles) * Has an arbitra…

Have you tried Rendaw's lua branch at all? I'm curious if that would remove your need for the 'run' command. At some point that will be merged to the mainline. Here's his tree: https://github.com/Rendaw/tup Is the "Line too long" error an error message from tup, or from the shell when it tries to fork a process? If it's the latter I'm not sure there is an easy fix. If it's the former maybe I was just lazy when implem…

Instead of making the tup process setuid root, just have a small chroot helper that is setuid and shell out to that. That way the entire tup codebase doesn't have to be trusted as root.

It still requires root for installation, but you can basically solve the security problem.

Re: Why Use Make

#243

Post by Peaker »

mshal wrote: post #225
Peaker wrote: post #84

Earlier quoted context omitted.

Yeah, though it is not that horrible since tup allows you to over-specify dependencies with very minor ill-effects (less parallelism, but no over-building). My list of short-comings besides that are: * No "run" command on Windows, means if you want portable tup you're stuck with its primitive scripting language (or reverting to Make-style hacks like ugly multi-phase build that generates the Tupfiles) * Has an arbitra…

Have you tried Rendaw's lua branch at all? I'm curious if that would remove your need for the 'run' command. At some point that will be merged to the mainline. Here's his tree: https://github.com/Rendaw/tup Is the "Line too long" error an error message from tup, or from the shell when it tries to fork a process? If it's the latter I'm not sure there is an easy fix. If it's the former maybe I was just lazy when implem…

I didn't try the Lua branch, that sounds OK. Though I'd really prefer to use Haskell :)

IIRC, the "line too long" was from tup.

I think the abstraction may have leaked after specifying the flag and using the setuid tup. But I may be wrong here.

Re: Why Use Make

#244

Post by Peaker »

niggler wrote: post #235
Peaker wrote: post #214

Earlier quoted context omitted.

Auto-generate script that generates header0.h with #include to header1.h, and header1.h with #include to header2.h, up to N=10. Of course, we don't know before generating the headers exactly what they'll need to #include. And N is determined solely by the existence of the #include, i.e: generation of header10.h does not #include header11.h and that should stop the build.

you can use most C compilers to autogenerate the dependencies in make format (see http://hastebin.com/kufajaqeso.sh for a sample makefile and script to generate the relevant code -- there's a commented line in header10.h that you should remove to prove to yourself that it indeed does the right thing)

Your solution isn't a solution, because it is not actually a Makefile.

Your shell script and Makefile both need to be run, in the correct order, by a meta build-system.

It won't re-generate just the right files when things change. Unless you always regenerate all the code, and that's gonna be very wasteful.

It won't parallelize things as possible. The code generation can be parallelized with parts of the build that don't depend on it.

It won't rescan just the right files (it will do more work than necessary).

Compare that with a real build system, such as tup or shake, that gets all of these properties right.

Re: Why Use Make

#245

Post by zwegner »

ycombobreaker wrote: post #238
zwegner wrote: post #233

Earlier quoted context omitted.

Interesting idea, I hadn't thought of that before. This only increases the complexity of the Makefile though, and for not much reason. Hashing can help in other circumstances (such as possibly skipping a linking step if the object files don't change), and it would really be much cleaner to have it as part of the build system. The last time I played around with generating code through make, it got real ugly real fast,…

> ... for not much reason There's actually a good reason to do this, but it is an edge case. A timestamp-based build system can do a no-op check with very little I/O. A hash-based build system has to read all of the file contents in order to determine that nothing has changed. Depending on the latency and bandwidth of your storage, this can make a big difference in incremental builds.

I was more talking about the need to implement this layer yourself, when it should be taken care of by the build system (though I don't know of any build systems that can easily implement your suggestion, since it has to somehow redirect the output of a code-generation step to another file). Agreed that there are performance differences, though in my experience hashing is quite acceptable even for large projects if used reasonably (only hashing inputs to build steps if they are also outputs of another build step).

Re: Why Use Make

#246

Post by packetslave »

ysangkok wrote: post #187
_phred wrote: post #171

Earlier quoted context omitted.

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

You can rip it off like this: https://github.com/ysangkok/terminal_web_player

Pretty majorly uncool to do that and not give credit or even a link to rachelbythebay.

Re: Why Use Make

#247

Post by sankl »

SomeCallMeTim wrote: post #234
gcb0 wrote: post #193

Earlier quoted context omitted.

So what? you are doing it wrong. there are lot's of people that use PHP for data crunching and bash for GUI and C without caring for managing memory properly. should we retire all languages that can be abused? also, your idea of how $ and $$ is wrong. but it could be that you messing up with = and := before that point :) so i guess your point stands. but again, all languages can be abused. blame the bad coder, not th…

> messing up with = and := Sorry, but I wasn't messing up those two. That's Makefile 101 knowledge; I'm talking about crazy advanced stuff, where := doesn't work the way you expect. Even := doesn't do what you want if, after the Makefile has been loaded and you've used := three times on the same variable, ALL the instances of that variable are replaced by the last assignment. Here's an example: FOO:=1 rule1 : echo $(…

Target specific variables do this job:

    rule1 : FOO:=1
    rule1 :
        echo $(FOO)

    rule2 : FOO:=2
    rule2 :
        echo $(FOO)

Re: Why Use Make

#248

Post by SomeCallMeTim »

sankl wrote: post #247
SomeCallMeTim wrote: post #234

Earlier quoted context omitted.

> messing up with = and := Sorry, but I wasn't messing up those two. That's Makefile 101 knowledge; I'm talking about crazy advanced stuff, where := doesn't work the way you expect. Even := doesn't do what you want if, after the Makefile has been loaded and you've used := three times on the same variable, ALL the instances of that variable are replaced by the last assignment. Here's an example: FOO:=1 rule1 : echo $(…

Target specific variables do this job: rule1 : FOO:=1 rule1 : echo $(FOO) rule2 : FOO:=2 rule2 : echo $(FOO)

Interesting. Didn't know this trick.

Turns out it wouldn't work for the usage pattern I needed (my example was simplified -- typically the variable settings would all happen in another file, and they couldn't happen on a target line because there wouldn't be a single target to use, in addition to just being ugly for that use), but it's good to know.

Post reply on HN