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

91–100 of 143 posts

Re: Build Tools – Make, no more

#91

Post by krick »

In fact I agree. I would be really glad if somebody explained me persuasively which one build-tools is the best one ever, so I could use it always and for everything, even when a shell-script would be enough. Yeah, it would be nice. But then, don't we have the same thing with about every class of software? Tens of text-editors and no perfect one. Many OSes and nothing sane. So many programming languages with overlapping functionality! And we won't even talk about such thing as linux distributions (and their packaging tools), pepsi&coca-cola… oh, it's not even software.

So, yeah, there are too many build-tools. Whatever.

Re: Build Tools – Make, no more

#92

Post by mhw »

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

I agree completely, and I think the blame rests with Ant and Java. Java's dependency management was painful enough to deal with in 'make' that Ant was built to support building Java projects. But in doing so the authors threw away the explicit file dependencies that made 'make' so powerful in the first place. Instead it got people to think in terms of a graph of 'tasks', each of which could either figure out its own dependency management, or more commonly ignore them completely. Most tools that followed seem to have gone down the 'graph of tasks' avenue, with 'graph of file dependencies' as an additional mechanism if you're lucky.

The huge Rakefiles you've seen could possibly have simply benefited from a rewrite in Rake. Rake has 'file' tasks which implement the file dependencies of 'make' but for some reason most users of Rake seem to ignore them completely.

Re: Build Tools – Make, no more

#93

Post by erikb »

Too wrote: post #84

Might go a bit off topic but i have to bring this up since 9 out of 10 make tutorials on the internet do the same horrific mistake as you just did, 11 out of 10 code bases out in the wild as well. In your make file example the .o files are just depending on the .cpp files, not the header files they include, the header files those included header files include and the files they include etc etc. This means nothing wil…

Is that solved with autotools? I'm not an expert, but I wonder why people talk about pure Make where a lot of bigger projects actually use autotools.

Re: Build Tools – Make, no more

#94

Post by tikhonj »

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 to contort yourself and bend over backwards to fit the logic you want into Make's limited and peculiar language.

Your build system is an integral part of your whole program and you want to treat it just like any other code. This means refactoring, this means modularity, this means libraries, this means no copying and pasting... All this is far easier with a system embedded in your main language than in Make. You can use your existing tooling, debuggers and frameworks to support your build system. If you're using a typed language, you can use the types to both constrain and guide your build files, making everything safer.

Using an embedded DSL integrates far better with the rest of your ecosystem than relying on Make.

Apart from making the logic of your build system easier to describe and maintain, an embedded DSL also makes arbitrary meta-tasks easier. You might want to monitor random parts of your build process, report to different services, connect to different front-ends (an IRC bot, a CI system...) and maybe even intelligently plug into the features of your main language. Wouldn't it be great to have a make system that's deeply aware of how your server is configured, how your type system works, what your compile-time metaprogramming is doing an so on?

You could just glue together a bunch of disparate scripts with a Make file. Or you could use a DSL and call these services through well-defined, maybe even typed interfaces! No need for serializing and deserializing: you can keep everything inside your system.

Sure, if you're just going to use your DSL as a different syntax for Make, you're not gaining much. But it allows you to do far more in a far better way, while fitting in more naturally with the rest of your code. I'm definitely all for it!

Re: Build Tools – Make, no more

#95

Post by hhariri »

ASneakyFox wrote: post #24

I get redirected with. "Your experience on this site will be enhanced by allowing cookies" I need cookies to read a blog post? Don't think so. Probably not worth the read

No. You don't. But EU laws requires that if you use Cookies for things such as Google Analytics or even just stats, you must inform the user. And you can switch it off.

Re: Build Tools – Make, no more

#96

Post by vorg »

revscat wrote: post #83
ndrake wrote: post #53

Earlier quoted context omitted.

I agree with a lot of your points, but can you explain the part about it doing a complete rebuild every time? It doesn't do that for me (unless I specifically tell it to).

My apologies: I just wrote a basic HelloWorld.java and a build.xml to go with it, and it looks like it doesn't recompile the class unless there is a change to the source .java file. So I was mistaken about that. Wonder what Gradle's caching, then?

> Wonder what Gradle's caching, then?

Let's hope it's catching another scripting language or two in its upcoming version 2 because having Groovy as the only option does it no favors.

Re: Build Tools – Make, no more

#97

Post by nn3 »

marshray wrote: post #87
nn3 wrote: post #76

Earlier quoted context omitted.

What is wrong wrong with just using the following. Given it would be nice if make had a builtin macro to do this, but it is not too bad to type out. depend: .depend .depend: ${SRC} ${CC} -MM -I. ${SRC} > .depend.X && mv .depend.X .depend include .depend Makefile: .depend

Because now make can't build a clean source tree. I believe make parses the entire Makefile before running it.

GNU make restarts when a Makefile: dependency changes. So it works perfectly fine. Try it ...

Re: Build Tools – Make, no more

#99

Post by laughinghan »

SchizoDuckie wrote: post #12

So he's saying use 'make' instead of gulp/grunt and then he submits an example where it's as easy as piping through GCC. He's making the wrong assumption that you don't need to setup a build environment when building with make, but to have gcc you will still also need to install g++ and build-tools. Also, he refers to building on Windows using yet another specialist tool, but have you recently tried building anything…

please show me a makefile [...] that will do the same as this

You mean like this?

    scripts: ${SCRIPTS}
            cat $^ | coffee -sc | uglifyjs -cm > build/js/all.min.js
Have you ever wished there was one-character symbol for the word "pipe", like maybe '|'? Such a symbol would even make all those .'s and ()'s redundant. While we're at it, if our build script is going to be in its own specially-named file, wouldn't it be nice if instead of namespacing under 'gulp', within the special build script file there was a DSL where you could specify the task name and its dependencies with a single character, like ':'? And instead of 'function() { return ...; }', your instructions were delimited with just indentation, like a Tab character?

Your example proves the opposite of the point you're trying to make. Starting from your example and trying to compress it with a DSL, you literally couldn't do better than Make syntax: the "gulp.task('" part is implicit, the "', function() { return gulp.src(" part is a single character (':'), every ").pipe(" is a single character ('|'), and ").pipe(gulp.dest('...'))" is a single character ('>').

I submit that's impossible, simply because this stuff took 2 years to evolve...

Before and during the entirety of those 2 years Make has been a better tool, for those of us JS coders who didn't dismiss it offhand as being always thousands of lines and only for dinosaur C coders.

Make has many problems, but taking thousands of lines to simply pipe together commands has never been one of them. Having to write .pipe() where in shell you could just do '|' has never been one of them, either.

Re: Build Tools – Make, no more

#100

Post by conradev »

humanrebar wrote: post #90
Too wrote: post #84

Might go a bit off topic but i have to bring this up since 9 out of 10 make tutorials on the internet do the same horrific mistake as you just did, 11 out of 10 code bases out in the wild as well. In your make file example the .o files are just depending on the .cpp files, not the header files they include, the header files those included header files include and the files they include etc etc. This means nothing wil…

Right. Make is mostly a kludge around the nonexistent module system in C and C++. It's so bad (specifically due to the way file preprocessing works), that you need to have large parts of a compiler to accurately determine what the dependencies of a source file are. This is why a decent module system should be the top priority for C++17, though it doesn't look likely so far.

Have you seen what Clang is doing[1]?

[1] http://clang.llvm.org/docs/Modules.html

Post reply on HN