Make for hipsters
mattandre.ws
mattandre.ws
From this perspective, a well structured Makefile can be thought of as a pipeline/graph of functions, that derive values (files) from previously known values (files).
Expressing a build process in this kind of way makes it possible to support incremental / distributed build in a fairly natural / obvious way.
It is less obvious how to support incremental / distributed builds for the more general kind of imperative build script that does a bunch of side effects (e.g. the style of build script you'd get using something like ant).
The syntax is simple:
.PHONY: all clean install
To be clear, they will rebuilt only if they are not already up to date relative to their own dependencies, right?
Phony is only about making sure that 'all' is seen as target, not as file or folder
.PHONY: all
all: ...
.PHONY: clean
clean: ...Of course you need to convert those externally -- with e.g. the C preprocessor for C files...
However, my biggest problem with Make is still that it does not allow for dependencies in the form of variables.
Of course, this is a work-around for variable dependencies. You'd have to change the filename somehow for every variable that you want to track.
There's a top level makefile with targets like "make debug" and "make release". Those invoke a secondary makefile that actually builds things and takes options on the command line. That way I can build different configurations to different directories without having to copy/paste all of the rules for each configuration of each file.
For example, the main makefile for Wren[1] has rules like:
debug:
@ $(MAKE) -f util/wren.mk MODE=debug
# Mode configuration.
ifeq ($(MODE),debug)
WREN := wrend
C_OPTIONS += -O0 -DDEBUG -g
BUILD_DIR := $(BUILD_DIR)/debug
else
WREN += wren
C_OPTIONS += -O3
BUILD_DIR := $(BUILD_DIR)/release
endif
# VM object files.
$(BUILD_DIR)/vm/%.o: src/vm/%.c $(VM_HEADERS)
@ printf "%10s %-30s %s\n" $(CC) $< "$(C_OPTIONS)"
@ mkdir -p $(BUILD_DIR)/vm
@ $(CC) -c $(CFLAGS) -Isrc/include -Isrc/optional -Isrc/vm -o $@ $(FILE_FLAG) $<
[1]: https://github.com/munificent/wren/blob/master/Makefile
[2]: https://github.com/munificent/wren/blob/master/util/wren.mk
.var.%: FORCE
@printf '%s' '$(subst ','\'',$($*))' | sed 's|^|#|' | $(WRITE_IFCHANGED) $@
-include $(wildcard .var*)
.PHONY: FORCE
Then, if a file depends on the value of a variable, I have it depend on .var.VARNAME. Of course, that means you may have to do something like $(filter-out .var.%,$^) in the command to generate a file.
a.o: a.c a.h
cc -o ${.TARGET} ${.ALLSRC:M*.c}
help:
@grep -P '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}'
build: ## Build the binary
clean: ## Clean the binary and intermediate files
distclean: clean ## Clean dependencies, intermediate files and binary
deps: ## Install dependencies
all: deps build ## Get dependencies and build binary
release: distclean all ## distclean + all
all Get dependencies and build binary
build Build the binary
clean Clean the binary and intermediate files
deps Install dependencies
distclean Clean dependencies, intermediate files and binary
release distclean + allSeriously, thanks. You solved a problem I had.
Second, if you're on OS X the `-P` flag is going to have problems [1]. Works fine if you just replace `grep -P` with something like `ack`!
help:
@awk -F ':.*##' '$$0 ~ FS \
{printf "%15s%s\n", $$1 ":", $$2}' \
$(MAKEFILE_LIST) | sortAnd it's really easy, and there's tons of literature on it on the internet. And it has a manpage.
The "bubble" is "most people that never used C/C++" (because outside of there, make is pretty rare despite its usefulness), and even if you've used C/C++ you are not necessarily familiar enough with it to know how to properly use it or to realize you can use it as a general tool.
Why would you expect people to magically know about (and prefer to others) a tool that's almost never used in the ecosystems they touch, or only behind the scenes?
...That may be the source of your problems if your devs are that inexperienced!
Grunt came out in 2011 and Gulp came out 2 years later with a superior (IMHO) code-over-convention approach. They've kinda been doing their thing since then.
Statements like seem to be nothing but FUD.
So the problem with choice is the number of people who also know that tool who can help you.
- you've got dependencies on some basic Unix commands (cp, rm etc.) in your tasks, so better rewrite that all to use your cross-platform language's facilities.
- XML, erm, no, JSON, shall be your only file format.
Or just install that Ubuntu on Windows thingy and be done with it.
I heard a legend that even the Windows developers run some flavour of unix.
Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages (although I guess you could argue some of the early Linux did as well (RPM)). It is sort of interesting how Make is sort of like local dependency management.
And Maven is still the only "package manager" I don't end up wanting to beat my head after using. For all the flak that pom.xml gets for being wordy, I know that after installing the JDK and maven all it takes is running `mvn package` and all my build plugins plus dependencies will be downloaded, installed, project compiled, tests run with whatever test runner I decided to use that year, and, assuming they passed, the project packaged up in a .jar or .war ready to be deployed.
Some more recent tools like cargo also get this right, but I don't have much of a use case for rust since the majority of my time is spend in web and desktop apps. But EVERYTHING being in one file and one tool makes getting down to business easy, there's no "make sure you run npm install before you call grunt/gulp/brocc/whatever" because maven handles it all.
Oh, as an added benefit, I don't scream about dealing with proprietary libraries like I do with .Net. The .Net SDK for our document management system has to be installed on all systems that use it via an MSI, yet the Java one is just a .jar with a couple dependencies, I whipped up a pom.xml for it in 30 seconds, pushed it to an internal maven repo and boom, done. Hell, at that point getting it packaged into an RPM (because I don't do "sprawl shit over the filesystem" deployments) took me another 3 minutes.
The build tools in Rust are incredible (given the maturity of the language). OCaml is also rapidly evolving as well (after a brief period of stagnation). I think those two languages would and probably even now make for excellent enterprise/business programming languages.
As a tech decision maker I would love to build future projects with Rust or OCaml but the cognitive load and talent needed for both those languages is higher sadly. The Ocaml build tools were a disparate mess back when I used to use it in college and for pet projects but I can honestly say there has been unbelievable strides forward.... and OCaml compiles so damn fast. I still can't believe Go users brag about compilation speed when I swear OCaml has been and still is much faster (IMO/anecdotally of course. I don't have numbers).
I can understand that entirely, it's way too easy to get ostracized for having a positive view on Maven or Java these days.
Java as a language has warts, but thankfully there's a thriving community around the JVM and a wealth of alternate languages to pick up. Still, you can pull Maven out of my cold, dead hands.
> As a tech decision maker I would love to build future projects with Rust or OCaml
I would love to use OCaml but the lack of interfaces to a lot of tools we use really bites, so I've settled for F# (can't wait for .Net Core support). Until there's DB2 for i drivers plus Laserfiche by some miracle supporting any programming language not deemed "enterprise-grade" I'm stuck with .Net or JVM languages for a lot of things I do daily :(
It's also declarative, BTW, which is a big improvement over Ant.
Maybe somebody should re-skin maven with a yaml based front end to attract the hipsters?
It's an improvement over pretty much anything else except for maybe cargo and whatever that haskell build tool is (name escapes me right now). Builds are not iterative/procedural tasks in my mental model, I simply have a list of inputs and desired outputs, so I agree that the declarative model of Maven is awesome.
I absolutely hate dealing with MSBuild files, Rakefiles, grunt/gulp/whatever because they all focus on a chain of tasks in a specific order. Why should I have to tell my build system how to do its job, I told you what I want done, just do it!
> Maybe somebody should re-skin maven with a yaml based front end to attract the hipsters?
A YAML to pom.xml converter would probably be a rather simple solution to this. Honestly, I wouldn't mind it either, there's a lot of noise in pom.xml that I could do without even as someone who likes Maven.
I guess you mean Shake.
With Maven everything is in ONE tool, and the ENTIRE configuration for the build is contained within your pom.xml. Custom maven repositories, what build plugins need to be installed, how the build plugins are configured, project dependencies, relationships between multi-module projects, what mojos run at what phases, it's all in a single easy to read, declarative XML file. MSBuild is a giant clusterfuck compared to Maven, and it's integration with NuGet is shoddy at best.
NuGet doesn't even allow me to specify repositories on a per-project basis to this day, everything has to be specified globally. There's a LOT more configuration required to get my build server set up to build .Net apps than anything compiled with Maven.
Solution level repositories might go some way to fixing your last issue, see https://github.com/voltagex/junkcode/blob/master/CSharp/zzCo...
As a personal machine maybe not, but even in the early heady days of Java, Unix deployment was the norm. I mean, what you're going to pick, one of those new-fangled NT servers or a proper IBM/Sun/HP-UX machine that has almost enough memory to run Oracle properly?
But given the "write once, run anywhere mantra", Java had something to prove, which lead to a lot ot NIH.
I'm feeling cranky every day, but just today this post is at the top of hacker news, and that's frustrating.
I guess this article could be worse: the number of times I see people reimplement poorly thought out clones of make and present them as the new thing that everyone should use is just absurd.
That said, you can prize Make out of my cold dead hands. Still my favourite build tool, and damned powerful once you learn to tame it.
If we stopped attacking the authors of articles, then it would be easier for them to write openly and less defensively, but unfortunately if you write anything on the internet, people will call you an idiot.
There are plenty of valid reasons why an established developer would never use Make, namely integration with the rest of their 'ecosystem'. Also, there's plenty of reasons for everyone to get in and use Make where appropriate.
Bah, you just take things too literally, and can't process/appreciate some obvious and light-hearted cultural signs.
A post that makes a joke comment != a post that discredits itself.
A post that warns that its own makefiles might be hacky != a post that calls makefiles inherently hacky (in fact this is obvious, since the post's goal is the inverse: to promote Make to people).
A post that tries to introduce Make to a whole bunch of devs who don't know about it != a post that doesn't notice that Make is used by many people for native programming on unices
Meanwhile they'll merrily pile up a thousand node modules into a towering pillar of bad, just to run the equivalent of a shell one-liner, and call it a job well done.
Separately, on the information side, there just aren't as many articles on old, but stable technology - and so if you open up HN, all they're seeing is the latest; if your team doesn't have good experienced devs on it and if you haven't learnt it in college/bootcamp then you'll pick what is publicized.
M4 is nice for processing text, I do use it and like it for that, but for defining dependencies among files and processes to go from source to compiled files, make itself is second to none. Autotools is basically one of the biggest exaggerations in the computers' history.
Furthermore, bmake exists and its include files are simply better.
Some stuff is genuinely awful.
- Sendmail was ubiquitous, but it was, according to anyone who'd had either fleeting or deep experience with it, a beardy wilderness of byzantine hacks and toxic waste dumps.
- All the WU apps had major exploits every few months.
- SysVinit sucked too, regardless of which replacement you prefer.
- RPM's macro-based .spec file format? Awful.
> pile up a thousand node modules to run the equivalent of a shell one-liner
If you don't like putting small modules together to achieve a task, I have some news for you about shell and Unix...
No, really. The "UNIX way" is not just "Use tons of small things to do a simple task, complexity of managing them be damned".
It is indeed "do one thing and do it well", but that "thing" is usually high level enough and ready to go -- not something you need a whole stack of dependencies, configuration, and lots of extra glue to use.
And of course those unix tools should be standard and evergreen -- not like npm module du jour that gets abandoned 2-3 years later or completely rewritten.
It really seems like you don't do a lot of node - which is fine obviously, but you seem to have very strong opinions about it.
The first part of this is a guess -- and it's wrong.
I can't speak for "most npm modules" (there are 200.000 or so -- i've only used around 1000, transitive dependencies included) but even those focused on specific high level tasks tend to depend on tons of lower level modules of varying utility and quality -- living them open to things like the "leftpad" fiasco.
And using "github and npm to track how active projects are before installing them" is not really an answer to the UNIX way described.
First because with UNIX you don't even need to check. You know all the basic tools, from grep and unique, to watch and make, are there for the long term (and have been for 3, 4 decades).
Second, because with npm, even checking for popularity doesn't tell you much. Even the most popular modules can be dropped by their authors, rewritten in just 1-2 years to behave differently, fall out of favor and languish etc. Heck that's true even for npm itself (e.g. the changes for version 3, like the flat sub-packages), gulp (see the way the new gulp handles dependent tasks and the new syntax required) and everything else.
Heck, 6 years ago Backbone was merely just released. And from then on we already went from it being most used and "hot", to Angular, React, React+Redux and who knows what's next.
Fair enough. Just saying that's the impression I get.
> even those focused on specific high level tasks tend to depend on tons of lower level modules
Yes. Good libraries do that. Smaller bits are made from bigger bits.
> living them open to things like the "leftpad" fiasco
I don't think you understand what the "leftpad fiasco" was. Small modules doesn't have anything to do with it - people who unpublish their modules on a whim does. And that's not been prevented.
> And using "github and npm to track how active projects are before installing them" is not really an answer to the UNIX way described.
Indeed. It's an answer to your concern about "npm module du jour that gets abandoned 2-3 years later or completely rewritten".
I'm not sure that npm, gulp changing significantly is a bad thing. Good software evolves over times. As long as the changes are clearly communicated I'm 100% down with that. Look how much better express got!
I think there's a marginal returns (or worse negative returns) border with this approach, where the overhead, over-generalization, and, finally, bloat, maintenance and management issues stemming from having too many small parts from disparate sources justify writing a specialized solution.
Leftpad would be an extreme case in point -- I'd put the bar even higher than that.
>Small modules doesn't have anything to do with it - people who unpublish their modules on a whim does. And that's not been prevented.
The "unpublish" thing just made the issue instantly apparent, but the core issue would still be there even if nobody could ever unpublish anything.
E.g. such small modules could get abandoned and neglected with bugs or security issues, could have extra bloat the parent library doesn't need (this might not hold with leftpad but would be true for anything a little larger that covers 10 things when you only need 2 and could code them yourself and be done with it), is now a dependency that has to be tracked and updated, it's not optimized for the particular use case it is used in, etc.
How well do you think a module with 1000 users is likely to be maintained, vs a create-your-own-wheel equivalent?
Do you think writing the latter is an adequate use of your time?
Do you think you'll discover all the edge cases?
How does writing your own wheel module rank when compared to working on features your customers want?
> - SysVinit sucked too, regardless of which replacement you prefer. > - RPM's macro-based .spec file format? Awful.
These are opinions, which is valid.
If you want to have some fun. install centos7 in a vm. Run yum update systemd. Reboot. Your vm is now bricked.
Rpm spec files can be annoying, but what is more annoying to me is the spec behavior changing between rhel/centos 5, 6 and 7.
Yeiks.
With that said, I agree about rpmspec's. They're simple to read and easy to maintain, it's part of the reason I chose CentOS and Fedora as our standard at work instead of Debian or Ubuntu.
In my current day-to-day, between work machines and my personal machines at home, I've only got to deal with init stuff occasionally, so picking up the Systemd way of doing things will take me a while.
Tools that gain traction today are those that can be learned incrementally by doing a google search and copy pasting a solution, one problem at a time.
Out are all those systems that have an underlying theory to them that has to be mastered first. As pointed out elsewhere, there is a perfectly good manual for make[1] that you can read.
My theory is that it has to do with shortened attention spans, and impatience perhaps bred by constant use of technologies with short stimulus response cycles [2].
[1] https://www.gnu.org/software/make/manual/make.html#Introduct... [2] Cellphones.
Now, I've only got one book on my desk and it's more of a coffee-table thing about html and css
I doubt it exists. Until then, I'll stick with my Node.js build tools, thank you very much.
Honestly, if anyone has an example of a makefile that can bundle my scripts, insert bundle links into my HTML which is compiled from jade and nunjucks templates, minify the JS, CSS and HTML and optimize my images...I'd love to see that.
Anyway, the point is, everyone likes the smell of their own farts. But, they still stink.
Windows is the only real challenge there, but with mingw, I can't imagine that it's a serious one.
One can argue that it would be better to solve that problem, rather than requiring everybody to sort-of solve it well enough to run one's own build.
Having said that, minimizing .js, .css, .html or .png files conceptually is the same as turning a .c into a .o, and bundling is conceptually the same as tarring or zipping a set of files, so I don't see why it wouldn't be possible to write a makefile that does that.
I see no reason at all to use a Makefile in that project other than it being your personal preference. It's completely non-standard for web projects and it will only serve to confuse and annoy the next developer who wants to work on your code.
Node.js, NPM, Gulp and Grunt are all orders of magnitude easier to get running on a wide variety of operating systems than your typical C/C++ build tools. Furthermore, you don't have to learn some cryptic syntax to use them. It's all Javascript and JSON.
Saying that gulp/grunt aren't real build systems because of one feature that you actually missed anyway is like saying that Javascript isn't a real programming language because it doesn't compile to assembly.
Practically nobody uses Make for JS outside of a few misguided folks. There are good reasons for that. One of them is that Make's craptic language is useless outside of that one single task. Another one is that Make sucks at cross-platform. It forces you to use OS tools that don't exist on every OS. Meanwhile, Node.js tools work everywhere.
For my part, as a Ruby developer, I detest rake and tend to write makefiles for my Ruby projects instead.
i use rake (very superficially) from time to time, and it seems fine. Any insights you have regarding its design after long-term or more indepth use?
You'd be surprised. Especially if they work outside C/C++, and do e.g. mostly web development, they neither care much, not know much about makefiles. At best the know to configure, make and make install something on their Linux, but most haven't even tried that.
>Also why is it for hipsters? Or is the article for hipsters?
The article is (supposedly) for hipsters. You seem a little challenged keeping with the latest "culture" (ain't we all), so let me explain.
What he means is that the article is not for seasoned veterans, or unfashionable people who delve in the old-fashioned word of GNU-tools and Make, but for "hipsters", e.g. the new-ish, young-ish developers, usually working with hip languages (and especially web, scripting, etc.), that are not rooted and well versed in the UNIX traditions.
>Why does the author call his own published notes factually inaccurate? Why is it hacky to use a makefile?
It's just a funny wording for the author to convey:
"I'm not a complete authority on Make and Make best practices, I'll just tell you what I know from experience about it. And I expect some Make-gurus to try yell at me about my suggestions being inaccurate/hacky etc, so I try to pre-empt them with this warning".
(Lots of fond memories arguing about the term in europe, where the word seems to lack its snobby, negative feel)
Yes, but this isn't the generic term "hipster", it's applied to a specific context, that is hipster programmers.
>Lots of fond memories arguing about the term in europe, where the word seems to lack its snobby, negative feel
I guess depends on where in Europe. In the place I'm aware of (e.g. not sure about Germany or nordic countries), it is indeed negative. E.g. this is about hipsters from a UK perspective:
https://www.youtube.com/watch?v=lVmmYMwFj1I&feature=youtu.be
Then he should say hipster programmers. I think of a less-parodied version of these guys: https://www.youtube.com/watch?v=IGkuxk-LPww
Also, the people I argued with were German. Perhaps a broad brush...
And really, my experience with Gulp had been the opposite of the snide "hipster" dismissals. I wish I could find clean examples via googling that weren't useless due to APIs completely changing, or due to using a library that's been deprecated in favor of another library that's been deprecated...because, man, who still uses a library after a year? :P
Somehow, though, I don't see make being a great replacement for my purposes. At the very least, it's not going to be any faster running Babel over a pile of files.
Despite being an obvious usability hole, this has never been fixed. Exacerbating the issue is the poor error message given upon encountering a space-indented line in Make:
Makefile:2: *** missing separator. Stop.
Well, which implementation of make should be fixed? The thing about these truly ubiquitous nix tools is that eventually people discover that there are unixes other than Linux.
…that said, a quick google found that this is* fixed in GNU make; check the docs for .RECIPEPREFIX here: https://www.gnu.org/software/make/manual/html_node/Special-V...
[Makefile]
indent_style = tab
https://github.com/aaronbassett/EditorConfig/blob/master/.ed...
You can now change the prefix for your recipes by setting the .RECIPEPREFIX special variable (https://www.gnu.org/software/make/manual/html_node/Special-V...).
That being said, with a properly configured editor I've actually found that TAB is an ideal character for the recipe prefix.
My personal preference for everything is spaces
And, not to sound harsh, but if you always "accept that there is a reason some things work in certain ways" without questioning if there may be a better way, well, you will always be stuck with the status quo!
Anyway, are you saying that accepting a tools established input format is to go with the status quo? I am all for breaking new grounds, but is this one really a priority?
Anyway, my point was, not everything needs to be customizable to your liking. Sometimes things have a set of simple rules you just have to follow. I for one like that we are limited to tabs, otherwise we would have problems with different number of spaces in the same file and by the way exactly how many spaces are a tab? I like 4 but maybe you like 8 or, god forbidden, 2?
Makefile:2: *** missing separator (did you mean TAB instead of 8 spaces?). Stop.
1998-09-04 Paul D. Smith <psmith@gnu.org>
* read.c (read_makefile): If we hit the "missing separator" error,
check for the common case of 8 spaces instead of a TAB and give an
extra comment to help people out.
Thanks for mentioning, I had no idea this special case was here!
au FileType make setlocal ts=4 sts=4 sw=4 noet
https://gist.github.com/zx2c4/11de49b2780c787b3ed5e1ee394857...
That's the Makefile I use on https://www.edgesecurity.com/ if you're interested. It also has in it some very simple ssh/rsync deployment mechanism. Since the deployment relies on the built files, I can simply run:
$ make deploy
Every webpage I manage has a variant of this, with all sorts of rules for building and managing things. It turns out to be much easier than grunt or ant or random bash scripts or vagrant or whatever else kids use these days.
You should read the manual, which is shorter than that page!
make is NOT:
alias:
commands
targetfile: inputfiles
commands to get targetfile to exist
%.css_min: %.css
sass stuff
.PHONY: release
# above is needed otherwise you won't build if there is a release/ dir
release: release-min.css
release-min.css: (list *.css_min files, there are helpers for it)
cat *.css_min > release-min.css
https://www.gnu.org/software/make/manual/make.html#Introduct...
Also available in print: https://shop.fsf.org/books-docs/gnu-make-version-381
info make
* (cd /path/to/something && make goal)
* You can use .DEFAULT_GOAL := goal_name to set the default target run by 'make' with no target name specified.
* Adding .SILENT will suppress make entering/leaving directory messages. Probably wise to be careful with one until you're 100% sure you're not ending up in an unintended directory doing nasty things.
* You can use $(COLOR) = `tput setaf x' and $(RESET) = `tput sgr0` to add colors to your make output. For example @echo "$(RED)ERROR!$(RESET)"
* Use if ! -f conditionals to start goals that rely on external scripts/programs. Otherwise make will run until it hits the error which will leave you with a partially completed goal.
goal:
@if [ ! -f ./scripts/blah.sh ]; then echo "ERROR: ./scripts/blah.sh not found"; exit 1; fi
@echo "without the if ! -f this command would run"
@echo "and so would this one"
@./scripts/blah.sh $(IMPORTANT_STUFFS)
@echo "but not this one"I had always, perhaps erroneously, thought that the very first goal in the file was the default one.
https://github.com/adewes/gitboard/blob/master/Makefile
Using the inotify tools it's even possible to automatically trigger a rebuild whenever a file changes.
For me, no need to use Gulp anymore, as Makefiles are easier to reason about, more composable and make use of existing infrastructure instead of reinventing the wheel over and over again.
Nope. You can say "make hello" and have make automatically use its default rules - which can be configured - to e.g. compile hello.c into a hello executable. I use this frequently.
Out of curiousity: how do you configure the implicit ruleset? I wasn't able to find documentation on that (the closest I found was https://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter..., which explicitly documents the Make implicit rules but says nothing about changing/augmenting them).
Other than that there's not much configuration, but the predefined rules are usually quite simple, so it's pretty easy to just write your own implicit rules if the predefined ones don't suit your needs.
So there's that. Make being such a good idea and a popular standard, there's no shortage of people implementing not quite compatible make-like-systems.
Another fun tip is make your makefile executable and try the first line like
#!/usr/bin/env gmake
or whatever seems appropriate. Or perhaps GNU make is installed as "make" on your OS or you use an "alternatives" link farm or whatever. Some people will flip out if you put arguments on that command line, others will pat you on the back and high-five. So there's that "fun".
include ${DEPENDS}
${DEPDIR}/%.d: ${SRCDIR}/%.${SRCEXT}
@mkdir -p ${shell dirname $@} ; \
$(CC) -MM ${INCLUDE} -mmcu='${AVRTARGET}' $< >> $@
%.o: %.c
$(CC) $(CFLAGS) -MMD -c $<
-include $(OBJECTS:.o=.d)Also specify -MP on the GCC command line, which causes GCC to emit an empty rule for all the header files, like this:
foo.o: foo.c foo.h bar.h
foo.h:
bar.h:
%.h:
I wonder how my makefile fails here.
that gets a 8/10 on my hipsterometer
If you want to see some interesting/convoluted Makefiles, get a very complex, large piece of software (something from Gnome, possibly) and use autoconf & automake to generate the Makefiles, then pour through them to see how they tick.
Make is fine. Automake is horrific.
If you're decent with Make and want to learn advanced tricks, then by all means go right ahead, but 95% of Make users will never need to delve into such details.
https://github.com/oNaiPs/npm-install-changed
http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...
[edit: formatting]
For example, Debian's packaging process is heavily optimized towards Makefiles that supply the standard targets, and you can reduce a lot of friction for packagers if you supply a wellbehaving Makefile with your program. (Even if developers would usually `go build` or whatever instead of `make`.)
Their makefiles work with GNU Make and BSD Make, don't know about nmake (AFAIR Windows).
----------------------------------------------------
foo: bar
bar:
----------------------------------------------------
.PHONY: foo
foo:
What I'd really love right now is a program which can look at a Go source tree and write make rules such that I don't have to run go build or go install unless dependencies have actually changed. It's really annoying to be pushing new images when nothing has actually changed.
If "what it does" means "build complex software projects" I think your claim is rather debatable.
GHC is currently switching away from make after having already overhauled its make-based build system two times:
http://research.microsoft.com/en-us/um/people/simonpj/papers...
And Make is terrible.
At least if want have to deal with more than one directory.
All these languages with their half-baked build tools that won't accept that they may have to play nice with other languages and their build tools are not helping.
Of course it is great when you write a language to also throw in a build tool, but in the end if the build tool re-implements 30% or so of make in a broken way I don't see the point.
Make does have its limitations, but most ordinary projects get nowhere close to reaching those.
You need to learn the Make build tool (easy) and then you need to learn bash scripting to get anywhere (argh!).
The OP has linked an example Makefile and I wouldn't be able to maintain/debug it without reading plenty of manpages:
https://github.com/Financial-Times/n-makefile/blob/master/Ma...
Also, a lot of the complexity is due to him being new to make:
asset%:
@if [ -e webpack.config.js ]; then ... fiIs make the right tool for executing such tasks? Well, it's not bad for some I guess, and ok if this one project is all you have.
Well, other build tools sometimes also do a lot more than make ever did. (And in some areas, perhaps less.)
Example: Cabal/cabal-install (for Haskell) can automatically fetch all your project's dependencies and automatically compile them for you.
> Make does have its limitations, but most ordinary projects get nowhere close to reaching those.
I suppose it depends on what you mean by "ordinary", but IME this Makefiles by virtue of being purely file-based is useless for most of my projects. There are a many langauges (e.g. Java/Scala, Haskell) where it just doesn't fit for normal development. As an example: Tracking intra-file dependencies for proper recompilation is really difficult to for Scala code without reimplementing a huge chunk of a Scala compiler. (I'd venture to suggest that you'd be foolish to even try doing this in Make.)
tup (http://gittup.org/tup) has a really nice way of handling interdependencies. They set up some filesystem magic to figure out which files were read while compiling a certain target, and record these files as dependencies for the target.
Another instance of a hard problem ("reimplementing [...] a Scala compiler") that turns into a very easy problem once you look at it from the right angle.
When I decided I needed a single build system to replace a hodgepodge of stuff, I looked at make because that was apparently the go-to thing.
It took me about 2 minutes to decide that I wanted no part of make. I'd assumed it was basically what Tup is. I'm lucky that I learned about Tup from a thread on this site, because it's made me so happy (especially once the initial pain was over... and yeah, you have to change).
So whenever I see these posts, I make sure that someone is mentioning Tup as a clean alternative.
edit: to be explicit, Tup is obsessed with speed and correctness, and handles incremental builds optimally (see Mike Shal's whitepaper on this). The "price" is that you can't modify files during a build. A file is either "regular" (not touched by build) or "generated" (produced wholly from one build rule). You have to describe the complete DAG up front. Because of all this, Tup will actually remove build targets when they're not needed, which I believe no other build system does. I could never go back.
> Another instance of a hard problem ("reimplementing [...] a Scala compiler") that turns into a very easy problem once you look at it from the right angle.
Only if you don't solve the problem fully. TBH, not even zinc solves the problem 100% and sometimes does a little bit of unnecessary re-compilation. It is very good, though.
One of the normal conventions for Daniel J. Bernstein's tinydns is to use make. No "projects" or "builds" are involved. The goal is not to create a program. Rather, make is used to ensure that the binary form of the DNS database is re-built whenever the system administrator has edited the text form. The administrator simply has to remember to run "make", and the Makefile re-builds, and atomically publishes, the new DNS database.
The simplest makefiles are of the scale exhibited at http://cr.yp.to/djbdns/run-server.html
But one can create significantly more ambitious makefiles than those. (-:
Sometimes you've better off having something that does exactly what you need, regardless of speed. Sometimes you need something fast, lightweight, ubiquitous, and reliable despite its quirks.