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

211–220 of 248 posts

Re: Why Use Make

#211

Post by cmccabe »

wtracy wrote: post #121
xymostech wrote: post #116

Earlier quoted context omitted.

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.

I have never been able to figure out how to cross-compile a project that uses CMake. GNU Make lets you just set some environment flags and drop in a different compiler.

CMake honors the same environment variables as Make. Just set them before running CMake.

CMake also supports cross-compiling. www.vtk.org/Wiki/CMake_Cross_Compiling

Re: Why Use Make

#212

Post by Peaker »

quotemstr wrote: post #135
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…

> 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). Make has exactly the same behavior with respect to additional dependencies. > All in all, these short-comings are very minor compared to Make's huge ones Like what?

> Make has exactly the same behavior with respect to additional dependencies

No it doesn't. If I overspecify that foo.o depends on foo.h, and I change foo.h, Make will rebuild foo.o even if it doesn't actually depend on foo.h. Tup won't.

> Like what?

Like incorrect builds, not supporting auto-generated code with dependency scanning, not scaling to large projects (slow builds, as demo'd by the benchmark page), lack of any kind of reports about the build, no guarantees at all about any output, and more.

Re: Why Use Make

#213

Post by Peaker »

quotemstr wrote: post #127
craftkiller wrote: post #41

Earlier quoted context omitted.

Personally I'd suggest Premake because it uses Lua instead of rolling its own scripting language. The world would be a better place if we could all agree on one scripting language for stuff like this so no one has to look up the syntax for things like creating arrays for every individual tool. Feature-wise premake isn't entirely caught up to CMake but it has everything important. Also the premake files look a lot cle…

> The world would be a better place if we could all agree on one scripting language for stuff like this It's called bloody "make". If Prolog is a language, so is make. Make is still a scripting language even if it's not boneheadedly sequential and imperative the way, say, Python is.

Make is simply not up to the job. It make writing correct build systems very difficult (hard to not under-specify dependencies). It does not support auto-generating code and then scanning it for extra build dependencies. It is a crappy tool and we should standardize on something better.

Re: Why Use Make

#214

Post by Peaker »

quotemstr wrote: post #169
Peaker wrote: post #64

Earlier quoted context omitted.

Adding a single extra phase is not enough, because you need an arbitrary number of phases to recursively build&scan all dependencies.

Can you provide a concrete example of a problem GNU make's secondary expansion feature cannot solve?

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.

Re: Why Use Make

#215

Post by cmccabe »

cdavid wrote: post #202
xymostech wrote: post #116

Earlier quoted context omitted.

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.

Using a macro language was already bad in the 90ies (autoconf/automake using m4), but using one in 2000 is just tragic. It is also impossible to debug, partly because of the abomination the cmake language is: even understanding where a variable is defined is hard, and because the language is so unexpressive, the Find*.cmake modules are often in the 1000s lines count. For all its suckiness, I take autoconf/automake ov…

I'm sorry, but your comment does not make much sense to me. autotools is mostly written in m4, with some shell snippets. Those are macro languages. If you don't like macro languages, logically you should not like autotools.

CMake is not "impossible to debug." In fact, it is a lot easier to debug than autotools-- partly because you end up writing so much less code. Also you don't have the three levels of "generated files generating other file generators" that you do in autotools.

For all its suckiness, I take autoconf/automake over cmake.

Well, we agree on one thing. autotools does suck.

Re: Why Use Make

#216

Post by mercurial »

quotemstr wrote: post #132
malkia wrote: post #87

Earlier quoted context omitted.

Make is the assembly/C language of build system. Lots of other systems just generate makefile compatible files (qmake, cmake, premake, others), but often these fall into overly complex traps trying to explain everything both with simple unique words, and then clashing into these. Make is very optimal at the stage it is, everything above or below it it's just not that optimal.

> Make is very optimal at the stage it is, everything above or below it it's just not that optimal. Right: GNU Make is at a local optimum for describing how to generate products based on rules and a dependency graph. I'd also wager it's close to a global optimum. GNU Make is certainly closer to that global optimum than Boost's jam or the countless homegrown XML-based things I've seen over the years --- make is powerf…

Well... If by XML-based things you are thinking of Maven, they're not really at the same level. Maven is much more higher-level, and is fully declarative, which is both a blessing and a curse. I would not describe it as a general-purpose build system, it's really made for the Java ecosystem, but in this context, it works well for a majority of projects, because they can follow the rails. And it does handle out of the box automated retrieval of dependencies, which is way outside the scope of make.

It has its hear in the right place, though. High-level build systems should strive to be as declarative as possible. It's the rest of the design which is problematic :)

Re: Why Use Make

#217

Post by zoobert »

mercurial wrote: post #216
quotemstr wrote: post #132

Earlier quoted context omitted.

> Make is very optimal at the stage it is, everything above or below it it's just not that optimal. Right: GNU Make is at a local optimum for describing how to generate products based on rules and a dependency graph. I'd also wager it's close to a global optimum. GNU Make is certainly closer to that global optimum than Boost's jam or the countless homegrown XML-based things I've seen over the years --- make is powerf…

Well... If by XML-based things you are thinking of Maven, they're not really at the same level. Maven is much more higher-level, and is fully declarative, which is both a blessing and a curse. I would not describe it as a general-purpose build system, it's really made for the Java ecosystem, but in this context, it works well for a majority of projects, because they can follow the rails. And it does handle out of the…

I think he was more talking about tools like Apache Ant.

Re: Why Use Make

#218

Post by throwawayG9 »

RexRollman wrote: post #61

From what the example accomplishes, it seems to be that it would have been easier to create a shell script. Is there something I am missing?

I just started learning about Make today, but according to the other comments in this post, there are lots of differences, like incremental builds and parallelism. It also checks things like file modification dates and whatnot.

Re: Why Use Make

#219

Post by Roboprog »

g8oz wrote: post #97

What about Java based tools like Ant or Maven?

Pro: they avoid starting another instance of the JVM for each "command"; they run on Windows.

Con: they are grotesquely bloated for humans to read and write; (as indicated elsewhere) they make any custom file generation "tasks" a PITA.

Personally, I'd like to strangle the bastard that invented Ant :-)

It would have been so much nicer to have just copied make syntax, and predefined a few macros for java-specific tasks which actually spun off threads within a JVM based interpreter.

Re: Why Use Make

#220

Post by lucian1900 »

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…

That is very cool, and it's something that will only get better if the Apple-proposed modules get widespread.
Post reply on HN