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

Practical Makefiles, by example

nuclear.mutantstargoat.com

Post reply on HN
Print view View original

11–20 of 29 posts

Re: Practical Makefiles, by example

#11

Post by bch »

krakensden wrote: post #9
ffkklf wrote: post #7

Earlier quoted context omitted.

ugh. CMake is atrocious. It covers maybe .1% of the cases that autotools handles while having some of the worst documentation known to man. Not to mention yet another language to learn. It's not more "modern" than autotools and it's in no way shape or form "newer" than autotools, seeing that automake/autoconf have been in active development since inception.

It does let you avoid shell, which makes cross platform stuff less fraught. This should not be interpreted as an endorsement of CMakes miserable, quarter-assed BASIC-in-almost-s-exprs language.

Upvoted, and re: documentation, I will say that I enjoyed the print book[0] when I was reading it years ago. Your comment re: quarter-assed BASIC... is about what I was thinking when I wrote https://news.ycombinator.com/item?id=9283016 -- a big missed opportunity.

[0] http://www.amazon.com/Mastering-CMake-Ken-Martin/dp/19309342...

Re: Practical Makefiles, by example

#13

Post by gshrikant »

Is anyone aware of the reasons for choosing the particular symbols that Make uses i.e. '@' (targets), '^' (list of dependencies) and 'I have admittedly limited experience with make and I always seem to forget what symbol stood for what. They don't seem to be particularly intuitive mnemonics to me.

For example, one could argue that '' for dependencies would be a tad clearer.

Re: Practical Makefiles, by example

#14

Post by cjdrake »

With all the news lately about Bazel, kind of refreshing to talk about this war-horse.

Consider: 1. Paul Graham recommends to "do things that don't scale". 2. Google designed Blaze when gmake started to scale badly.

Chances are, gmake plus some shell scripts and language-dependent build flows is all you really need. Worry about replacing it with something more scalable when you actually have that problem :).

Re: Practical Makefiles, by example

#16

Post by flohofwoe »

It's interesting that under the section "Handling cross-platform differences" the author calls 'uname -s'. It's not cross-platform if you ignore Windows (and requiring to install cygwin doesn't count), or cross-compiling scenarios. Also makefiles don't help all that much if you want to work in the platform's 'native' IDEs (like Visual Studio or Xcode). These 3 points (cross-platform, cross-compiling and IDE support) are exactly the points that meta-build-systems like cmake (or scons, or premake) fix. Remember that cmake isn't a replacement for make, for command line compilation it usually makes sense to let cmake generate makefiles (except on Windows).

Re: Practical Makefiles, by example

#17

Post by mewo2 »

gshrikant wrote: post #13

Is anyone aware of the reasons for choosing the particular symbols that Make uses i.e. '@' (targets), '^' (list of dependencies) and ' I have admittedly limited experience with make and I always seem to forget what symbol stood for what. They don't seem to be particularly intuitive mnemonics to me. For example, one could argue that ' ' for dependencies would be a tad clearer.

I always think of '^' and 'I'm not sure what the deal is with '@' though.

Re: Practical Makefiles, by example

#18

Post by exDM69 »

radialbrain wrote: post #2

To anyone implementing the automatic dependency generation mentioned in this article, you can actually make things even simpler by combining the compiling and dependency steps. This works because if you add a new dependency to a file, that information will only be needed for the next build - the current file will already be considered out of date seeing as it was edited to add the #include. gcc -MD -MP foo.c -o foo.o…

I second this, using CFLAGS=-MMD or -MD makes writing a Makefile a lot more simpler. This also gets rid of the need to add a rule for building dependency files and you can rely on the built-in rules (see `make -p`) to build object files.

A good Makefile should have any rules for building object files if you're using a language like C or C++, which Make has built-in rules for. If using another language, adding a few generic rules should be enough.

Here's a Makefile template I've been using for some time. It may look complicated initially but only the first 70 or so lines are the actual beef. The rest of the Makefile is helpful rules for tooling (tags, cscope, coverage, profile) but that doesn't work too well at the moment. It also supports out-of-source-tree builds (using vpath to locate source files, object files and other outputs go under $PWD, vpath is does not work for object files).

https://github.com/rikusalminen/makefile-for-c

Re: Practical Makefiles, by example

#19

Post by exDM69 »

pdq wrote: post #5

One other dependency often forgotten is on the Makefile itself. This way if the Makefile changes, everything gets rebuilt: DEPS = Makefile %.o: %.c $(DEPS) $(CC) $(CCFLAGS) -o $@ -c $

This may or may not be what you want, depending on the use case. If you change an important variable in the Makefile (e.g. CFLAGS), you might want to recompile everything. However, if you're just adding a new source file to the Makefile, you definitely do not want to rebuild everything.

I prefer to run `make clean` manually when necessary rather than adding a rule to rebuild everything "just in case". But I can imagine that this might be useful in some cases.

Re: Practical Makefiles, by example

#20

Post by golergka »

Very appreciated. I'm trying to make small hobby projects with a simple C and Makefiles, to get a taste of a stripped-down, basic environment, and after I got accustomed with basic Makefile usage (which is taught in any of thousands tutorials on the matter), I found myself lacking coherent and easy to read material that would get me to a more advanced level. Tutorials and stack overflow questions either cover really basic stuff or suggest things that seem like awful practice in the first glance, and GNU Make manual is written in way that suggests you sit down and read it for a few hours instead of just giving you a quick and sane way to solve a particular problem.
Post reply on HN