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

Build Tools – Make, no more

hadihariri.com

Post reply on HN
Print view View original

111–120 of 143 posts

Re: Build Tools – Make, no more

#111

Post by ChuckMcM »

rafekett wrote: post #47

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)…

It can be worse than that, one build system I looked at built everything every time. Why? Because "Computers are fast enough that trying to figure out exactly what needs to be rebuilt is an anachronism, this can rebuild everything in the time it took that crufty old system to figure out what it actually had to build."

I've given up trying to educate folks, I just make a note to check in with them, 6 months to a year later, to see if they are still building everything.

Re: Build Tools – Make, no more

#112

Post by shoo »

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" : https://github.com/ndmitchell/build-shootout . 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 http://facebook.github.io/buck/ . There's a little discussion about `gerrit`'s move to `buck` here: http://www.infoq.com/news/2013/10/gerrit-buck .

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.

Re: Build Tools – Make, no more

#114

Post by idlewan »

BoppreH wrote: post #106

I think one reason is because Make is built with Shell, which is always one step (and one letter) away from hell. For example: clean: rm -rf *o hello 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…

I'd expect all developers using make to know about this and never have this problem thanks to one simple thing: sticking with sensible names (no spaces, no brackets, no stars and other special characters in the name - hello underscores!).

It's an easy rule.

    Just like I prefer static strong typing...
You probably don't use any special chars or spaces for identifiers in whatever the language you're programming in. This is just applying a similar rule to the files of your project.

Re: Build Tools – Make, no more

#115

Post by cgrubb »

tikhonj wrote: post #94

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…

Your build system has types? Is that so you can catch errors at compile time instead of run time? Who builds the build tool?

Re: Build Tools – Make, no more

#116

Post by shadowmint »

badman_ting wrote: post #86
vinkelhake wrote: post #50

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, Mak…

I find them irritating for the same reason. It reminds me of the jQuery cycle: use jQuery for everything -> decide that depending on frameworks is lame -> use "vanilla JS" for everything -> realize this requires polyfills and various other inconvenient, inelegant things -> either go back to using jQuery, or gain a much deeper understanding as to why everyone uses it.

I doubt the analogy is apt.

Make is not an amazing (abit slightly bloated) meta tool that solves all your problems on all platforms (abit slowly).

Make is vanilla javascript, along with all the bumps and hassles of not working correctly on multiple platforms, having odd obscure syntactic oddities and only kind of supporting various operations in newer versions (which may or may not be available on various platforms).

The newer build tools are trying to do exactly what jquery does, and abstracting away those rough edges for a consistent build behavior with better syntax.

Going back to make is the 'use "vanilla JS" for everything' step in your list above, not the final step.

Re: Build Tools – Make, no more

#117

Post by BoppreH »

idlewan wrote: post #114
BoppreH wrote: post #106

I think one reason is because Make is built with Shell, which is always one step (and one letter) away from hell. For example: clean: rm -rf *o hello 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…

I'd expect all developers using make to know about this and never have this problem thanks to one simple thing: sticking with sensible names (no spaces, no brackets, no stars and other special characters in the name - hello underscores!). It's an easy rule. Just like I prefer static strong typing... You probably don't use any special chars or spaces for identifiers in whatever the language you're programming in. This…

For source code files I agree completely; but the build system will encounter other types of files that aren't so strict.

Maybe you downloaded something and it came with a bracket because that was in the page title. Or you copied a duplicated file and your system helpfully appended " (2)" at the end. Or there was an excel file updated by someone not so technical and this person didn't know they have to strip accents from the words in their native language (possibly losing meaning). Or someone saved their "Untitled Document.txt". Or you needed to include a date in the directory name. Or you are just human and didn't mean to break the build by pressing the biggest button on your keyboard when saving a file.

And remember "break the build" here is not "a red light flashes and you get an email". It means you get unknown behavior throughout the process, including security features and file removal.

Strict rules for source code file names are good because names usually bleed into the language itself. Python file names become identifiers when you import them. Identifiers in turn are strict because parsing is strict, and there are many good reasons for strict parsing in general purpose languages.

Lacking accent support in file names, as some very popular software do, is terrible. Lacking support for spaces is just atrocious.

I love shell, I use it daily for one-off tasks, but I don't think it's a good fit to manage the build system of a project.

Re: Build Tools – Make, no more

#118

Post by muteh »

cgrubb wrote: post #115
tikhonj wrote: post #94

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…

Your build system has types? Is that so you can catch errors at compile time instead of run time? Who builds the build tool?

I know you're just being glib, but here are some answers: * build doesn't mean compile * you can compile your build process and then use that to actually run your build * the benefits of typed languages go beyond catching errors at compile time

Re: Build Tools – Make, no more

#119

Post by geuis »

hhariri wrote: post #54
geuis wrote: post #3

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.

I know. I don't agree with it much either and I found this least intrusive (wasn't aware of issue on mobile). If I can find a better solution, will change. Thanks.

Sorry if that came across as negative. I like to help point out UI problems from time to time but I think it comes across as criticism sometimes.

Re: Build Tools – Make, no more

#120

Post by daemin »

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.
Post reply on HN