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

191–200 of 248 posts

Re: Why Use Make

#191

Post by shadowmint »

McUsr wrote: post #175
shadowmint wrote: post #160

Earlier quoted context omitted.

Sure, make is a generic tool, and you can do anything with it; from parsing json files, to compiling C code, to formatting documents. ...but so are bash scripts. I wouldn't advocate actually using either of these though, unless the situation is appropriate. Every system and platform has different requirements, and its a bit of a big ask to want make to be 'the right tool' for all of them. Certainly, I'd never use mak…

I just want to inform you that GNU make indeed is very good for c projects as it can read the dependency files made by gcc (and clang), so you get very small very readable makefiles, that takes care of tracking the dependencies for you. http://wiki.osdev.org/Makefile

Really?

There are a lot of people who use makefiles for C projects, but most of those people don't write them by hand.

They use a frontend that generates a vastly complex and arcane makefile using either automake, cmake, qmake, etc.

These makefiles are utterly unmaintainable and deserve a place next to 'goto' in the section labeled 'considered harmful'... but they serve a purpose; correctly collecting build settings, templates and metadata and using those to construct the correct makefile.

That doesn't count as 'using make'.

There are a vanishingly few projects that actually use make; google for it's NDK builds (and a few other things; but these are massive recursive makefile monsters that you have a tiny safe api to work with), LUA with its 15 makefiles, one for each platform. There are a couple of other examples, but not many. I can't think of any big ones off the top of my head.

I think we can safely say that writing a Makefile to build your C code is a bad idea.

Re: Why Use Make

#192

Post by zem »

all these "make for beginners" tutorials i've seen point out (correctly) how make is, at its most basic, just a dsl for specifying a dag.

it seems to me that it would be pretty useful to have a tool that let you build up said dag graphically, perhaps dragging and dropping files from an explorer pane, and then generated a makefile under the hood.

add in simple "infinite undo" git support that checkpointed every time you built with new inputs, and you'd have a dead simple way for non-programmers (who nonetheless have to do some programming to work with their data) to get the benefits of programming best practices. does such a tool exist?

Re: Why Use Make

#193

Post by gcb0 »

SomeCallMeTim wrote: post #189
ycombobreaker wrote: post #186

Earlier quoted context omitted.

> I agree that Make should be retired, and yet I'm typically the "Makefile expert" where ever I work. I'm the Makefile expert in my software shop. I still use GNU Make simply because I haven't found anything "better enough" to justify switching a toolchain. CMake was probably the closest--and that mostly because I know that it works for KDE, so I should be able to learn by example. What sort of complexity do you thin…

>So where have you seen it suck the most? When people (myself included) start taking advantage of the fact that Make is Turing-complete and writing arbitrary "programs" in their Makefiles. It typically starts simple; you want to do something like build ALL the files in a folder, so you use a wildcard. Then you want to add dependency checking, so you use the wildcard to convert between .o to .d, keeping the same folde…

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 the tool.

Re: Why Use Make

#194

Post by spc476 »

shurcooL wrote: post #188

This is a nice article, especially on a general level of writing scripts that automate work so you don't have to redo it manually. I want to point out one thing. targetfile: sourcefiles command This violates DRY, there is duplication between command and source files (and target file?). In theory, it should be possible to automatically deduct the source files from the command. It's far from easy in the general case, b…

I don't understand. In make, I can do:

    program : f1.o f2.o f3.o
            $(CC) -o $@ $^

    f1.o : f1.c f1.h f.h 
            $(CC) -c -o $@ $
Where "$@" is the target, "$^" is a list of the source files, and "$<" is the first source file. And that's if you want to be verbose.

Re: Why Use Make

#195

Post by ycombobreaker »

SomeCallMeTim wrote: post #189
ycombobreaker wrote: post #186

Earlier quoted context omitted.

> I agree that Make should be retired, and yet I'm typically the "Makefile expert" where ever I work. I'm the Makefile expert in my software shop. I still use GNU Make simply because I haven't found anything "better enough" to justify switching a toolchain. CMake was probably the closest--and that mostly because I know that it works for KDE, so I should be able to learn by example. What sort of complexity do you thin…

>So where have you seen it suck the most? When people (myself included) start taking advantage of the fact that Make is Turing-complete and writing arbitrary "programs" in their Makefiles. It typically starts simple; you want to do something like build ALL the files in a folder, so you use a wildcard. Then you want to add dependency checking, so you use the wildcard to convert between .o to .d, keeping the same folde…

> some of my Make variables are referenced with $(VAR), and some with $$(VAR), depending on whether I want them to grab the CURRENT version of the variable or the calculated version.

Hah, my latest Makefile work has been a set of functions which generate Make-syntax output, which then gets $(eval)ed. I hear you on the debugging nightmare that this can be: does a given variable get resolved when the function is first $(call)ed, when the block gets $(eval)ed, or when the recipe is invoked? But IMHO it's not too bad to do printf-style debugging. Replace $(eval $(call ...)) with $(error $(call ...)), then work backwards from there.

It also helps to be very disciplined about immediate assignment (`var := stmt`) and to always use recipe-local variables, rather than global variables.

I do feel like all of this aspect would be cleaner in Python or Lua... but the problem is, the _rest_ of the build, which more people interact with on a daily basis, gets more complex when that happens. Because there are always the ancillary targets and recipes where normal Makefile syntax works just fine.

Thanks for the NDK reference, I'm interested in seeing other "ugly" Makefile support infrastructure for comparison :)

Re: Why Use Make

#196

Post by ycombobreaker »

gcb0 wrote: post #193
SomeCallMeTim wrote: post #189

Earlier quoted context omitted.

>So where have you seen it suck the most? When people (myself included) start taking advantage of the fact that Make is Turing-complete and writing arbitrary "programs" in their Makefiles. It typically starts simple; you want to do something like build ALL the files in a folder, so you use a wildcard. Then you want to add dependency checking, so you use the wildcard to convert between .o to .d, keeping the same folde…

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…

> also, your idea of how $ and $$ is wrong

No, he's spot-on about that. If you are using a function from within a Makefile to generate Make code which then gets $(eval)ed, then then inner function must output $${variable} so that the outer function sees ${variable} and does not immediately resolve it.

It's hairy. Hairier than macros in C. But like any other specialization, it can potentially save an immense amount of time for the rest of the tam.

Re: Why Use Make

#197

Post by ycombobreaker »

plorkyeran wrote: post #164
quotemstr wrote: post #133

Earlier quoted context omitted.

> This page compares make to tup. This page is a little biased because tup is so fast. How fast? This one time a beam of light was flying through the vacuum of space at the speed of light and then tup went by and was like "Yo beam of light, you need a lift?" cuz tup was going so fast it thought the beam of light had a flat tire and was stuck. True story. Anyway, feel free to run your own comparisons if you don't beli…

For very large projects the build system can quite easily become the bottleneck when just changing a single file, which also happens to be the most important use-case for developers. In extreme cases a no-op build with make can easily get to 15+ seconds.

> In extreme cases a no-op build with make can easily get to 15+ seconds.

I have never seen cases so extreme, but my opinion on the matter is that this is a "build smell". If the Makefile has to resolve a DAG this large, that means that developers have to worry about compile- or link-time interactions this large, as well. 100k source files all linked into a single executable is more complex than 10k source files split across 10 executables, and a handful (say <100) of headers which represent "public" APIs. Because if you have 100k source files and your developers haven't all killed themselves already, then there are some firewalls separating various modules already. Formalize it at an API level and split apart the builds, so that it's _impossible_ for anything outside of the API itself to trigger a full rebuild.

Re: Why Use Make

#198

Post by ycombobreaker »

shadowmint wrote: post #191
McUsr wrote: post #175

Earlier quoted context omitted.

I just want to inform you that GNU make indeed is very good for c projects as it can read the dependency files made by gcc (and clang), so you get very small very readable makefiles, that takes care of tracking the dependencies for you. http://wiki.osdev.org/Makefile

Really? There are a lot of people who use makefiles for C projects, but most of those people don't write them by hand. They use a frontend that generates a vastly complex and arcane makefile using either automake, cmake, qmake, etc. These makefiles are utterly unmaintainable and deserve a place next to 'goto' in the section labeled 'considered harmful'... but they serve a purpose; correctly collecting build settings,…

> I think we can safely say that writing a Makefile to build your C code is a bad idea.

I don't think that's a safe assumption at all, I think that's a dangerous overgeneralization. You're only considering open-source projects... and as you point out, both NDK and Lua (projects in the embedded space) use Make. I would not be surprised to find hordes of non-OSS embedded developers using Make natively precisely _because_ it is the "assembler" of build systems.

Re: Why Use Make

#199

Post by gchpaco »

ycombobreaker wrote: post #197
plorkyeran wrote: post #164

Earlier quoted context omitted.

For very large projects the build system can quite easily become the bottleneck when just changing a single file, which also happens to be the most important use-case for developers. In extreme cases a no-op build with make can easily get to 15+ seconds.

> In extreme cases a no-op build with make can easily get to 15+ seconds. I have never seen cases so extreme, but my opinion on the matter is that this is a "build smell". If the Makefile has to resolve a DAG this large, that means that developers have to worry about compile- or link-time interactions this large, as well. 100k source files all linked into a single executable is more complex than 10k source files spli…

Typically this shows up in recursive make projects with lots of sub projects—it doesn't take that much time to stat every file in question but reinvoking make sixteen times can be quite slow.

I don't deal with this by not using make, I deal with this by not writing recursive makefiles.

Re: Why Use Make

#200

Post by ycombobreaker »

zwegner wrote: post #20
fafner wrote: post #3

Using make gets quickly really ugly. I wrote many Makefiles in my life and if you have to try to stick to GNU Make. At least it provides some basic functionality. But even that gets nasty quite soon when you need a simple thing like conditions with "and" or "or". If you have to write portable Makefiles ... well fsck. http://www.conifersystems.com/whitepapers/gnu-make/ There were recent discussions about adding GNU Gu…

Here's a very simple but powerful build system by the author of that paper: http://code.google.com/p/make-py/ It's just a single ~400 line python script. The only major feature that's missing IMO is hash-based rebuild detection, which is essential if you're using much auto-generated code.

> The only major feature that's missing IMO is hash-based rebuild detection, which is essential if you're using much auto-generated code.

I'm guessing that your goal here is to avoid a recompile if the auto-generated content did not change. This is not a problem for timestamp-based build tools if you add a single step: auto-generate your output to a temp file, and only replace the target with the temp file if the file shows a difference. The program `install` will do the 'copy iff file contents have changed' part for you, so it's really just two extra lines in the Makefile recipe.

Post reply on HN