Live data from Hacker News

The Ultimate Frontend Build tool: make

algorithms.rdio.com

101–110 of 121 posts

Re: The Ultimate Frontend Build tool: make

#102

God I hate make. I hate make so very, very much. Compiling code isn't that hard. I swear to the programming lords on high it isn't. Here's a wonderfully useful open source project - Google gperftools [1]. It includes TCMalloc amongst other things. The Makefile.in is 6390 lines long. Configure is 20,767 lines long. Libtool is 10247 lines long. That's fucking insane. Compiling OpenSource is such a pain in the ass. Part…

What you are describing is autoconf, not make. Make by itself is actually a very handy tool for performing tasks that have a dependency graph. Autoconf.. Well, I can't disagree. It's a hack built on top of a hack and should probably be rethought. Once autoconf is done generating Makefiles, make itself is generally trouble-free. http://freecode.com/articles/stop-the-autoconf-insanity-why-...

I'm okay with autoconf. Automake however is an abomination.

Re: The Ultimate Frontend Build tool: make

#103

The problem with make is not that it's bad, it's that's it's only really good at doing two things: 1) mapping a source pattern to an output pattern 2) managing dependencies between rules To be fair it's good at those, and often the sorts of things you can do with a rule are quite complex (being basically shell scripts). However, the problem is that 1) it's an obscure DSL and 2) that it is really rubbish at doing more…

There are other benefits to make. First, you'll need to ask users to install grunt, whereas make is standard and is just there (except for Windows, probably). Second, make provides a language that is optimised to express the information it needs, whereas grunt uses a JSON file. It gave me headaches when I needed to edit grunt config at my last job, and I never touched grunt ever since. Third, all the tasks you've specified can be done with standard UNIX utilities, whereas you depend on third-party libraries with grunt. Also, I do not think that any of those tasks are complex.

I'd rather rewrite a 4-LOC shell script in my new project, instead of depending on a build tool that depends on a non-standard, infant runtime itself, and also depends on third party libraries for deleting files.

Re: The Ultimate Frontend Build tool: make

#104

God I hate make. I hate make so very, very much. Compiling code isn't that hard. I swear to the programming lords on high it isn't. Here's a wonderfully useful open source project - Google gperftools [1]. It includes TCMalloc amongst other things. The Makefile.in is 6390 lines long. Configure is 20,767 lines long. Libtool is 10247 lines long. That's fucking insane. Compiling OpenSource is such a pain in the ass. Part…

What you are describing is autoconf, not make. Make by itself is actually a very handy tool for performing tasks that have a dependency graph. Autoconf.. Well, I can't disagree. It's a hack built on top of a hack and should probably be rethought. Once autoconf is done generating Makefiles, make itself is generally trouble-free. http://freecode.com/articles/stop-the-autoconf-insanity-why-...

Everyone says that, until they're put in charge of babysitting an old HPUX or AIX box and it's time to install something. Then no one complains about Autoconf again (though they can't bring themselves to praise it, either).

Automake, on the other hand...

Re: The Ultimate Frontend Build tool: make

#105
post #2

Although make does have a lot of weird quirks, its winning strength is that it is installed virtually everywhere.

That's true, but it's the same argument that justifies Javascript :)

The thing I don't like about make is the poor debuggability when something goes wrong. I having been using make for 15 years and I'm ready for something that gives me more traceability.

A poster above had it right - it's perfect for mapping input files to output, but inbetween and above that, it stumbles pitifully.

Re: The Ultimate Frontend Build tool: make

#107
post #12

Earlier quoted context omitted.

Why not drop the "neck-bearded" bit? Evi Nemeth had more Unix chops than 99.86% of the people on HN and no neck beard.

Neck-Beard is not about the beard, it's a state of mind.

Your 'inner' neck beard, as it were.

Re: The Ultimate Frontend Build tool: make

#108
post #82

Earlier quoted context omitted.

Actually, most contemporary hipster build systems are bad reimplementations of make. Yes, make is a PITA, but every other build system is worse.

UI have yet to see a 'hipster build system' that mixes shell and make language or uses punctuation for variables. Are all things made since 1977 hipster?

Yes.

Get off my lawn, hippie.

Re: The Ultimate Frontend Build tool: make

#109

God I hate make. I hate make so very, very much. Compiling code isn't that hard. I swear to the programming lords on high it isn't. Here's a wonderfully useful open source project - Google gperftools [1]. It includes TCMalloc amongst other things. The Makefile.in is 6390 lines long. Configure is 20,767 lines long. Libtool is 10247 lines long. That's fucking insane. Compiling OpenSource is such a pain in the ass. Part…

I've come to think that build systems are a very personal utility. Everyone has their favourite. Mine's fabricate.py, for example. Over time I've built up a library of script snippets and shortcuts and so on which I'm familiar with, comfortable with, and exactly fulfil all my use cases. It's all very clever. :) Yet when I download some random project's source code, I groan at any sophistry in the build process at all…

Thank you for making me feel a little bit vindicated. This is precisely how I build my current side project, I essentially mask all of the build/runtime options/tweaking behind a shell script and call all of it through that. ('./run remake', for example, or './run with valgrind' if you're in a debugging mood)

For me, the makefile itself wasn't the problem, I've been rather aggressive to keep it as pretty much just a dependency enumeration with flag lists and (arrogantly) it is rather clean, but the runtime flags/things I need to wrap the executable around pushed me to the script.

(I honestly worried that this was sloppy since it indicated exactly what it did, mask really ugly complexity behind a shiny frontend, which always makes me wonder if that complexity wasn't undue, but it does give the advantage that your last paragraph mentions, that it gives a more modular pseudocode of the various components of building/running.)

Re: The Ultimate Frontend Build tool: make

#110
One thing I should note - the difference here is that make enforces working in a Unix-like environment...which cuts out Windows users. I know, most devs will use OS X or their favorite flavor of Linux anyway, but at least personally speaking, there are occasions when I do some development on Windows.
Post reply on HN