Earlier quoted context omitted.
I agree. It has its merits, but it's hard for me to get around my visceral reaction to the fact it just bombs on filenames with spaces in them.
You can escape spaces in makefiles.
"can" or "have to"?
Makefiles for web work
51–58 of 58 posts
Re: Makefiles for web work
#52Earlier quoted context omitted.
Meh. OK. Though almost always, "run tasks" implies some level of state. Are you tasks truly all idempotent and parallelizable? If not, maybe they should produce output and be tracked by dependencies? If so, then you probably have bugs in your "task runners" that will show up in weird ways. It's absolutely true that ".PHONY" looks like a hack; it was sort of meant to. In general you shouldn't be using it, except maybe…
> Though almost always, "run tasks" implies some level of state. Yes! But isn't one of the major design principles of Make that the host filesystem is the container for the state? (iirc Make decides when to re-run rules based on when the timestamp on a target is older than the timestamp on an input file)
Sure, so where does that state get stored in a pure "task runner" tool? Attempts to muck with this metaphor ("state is what is left behind when the tool is not running") are among the worst mistakes made by build systems. It's a feature, not a bug, and everyone who believes otherwise ends up rediscovering it the hard way.
Re: Makefiles for web work
#53Earlier quoted context omitted.
Why do you have spaces in the filenames of your project in the first place? They require annoying escapes to work with essentially everywhere, notably including on the web. You have complete control over the filenames in your project... why are actively choosing to use a space character? I can see a better argument for wanting to use an apostrophe in a filename than a space character :(.
Because I wanted the title of my blog posts to match the file name, so I didn't have to remember which markdown file was which post.
Which sounds cool and all, except I bet the URL doesn't have a space character in it, right? And so, now you have a weird mismatch between the files on disk and the site structure.
Re: Makefiles for web work
#54It's interesting, but I can't help but think that by the time you're adding `.PHONY` after most rules, you're not using the right tool for the job. (I generally find a small set of shell scripts work, or just three or four rules in the package.json file I can access with `npm run`).
In our case we have most of the processes that are run by make tee their output into a project log directory. Then the make rules can use the log file itself as the dependency for the target. Works great in a lot of cases, and, you get the added benefit of being able to easily go back and observe previous process output and compare it across projects.
Oh wow, I can’t believe I’ve never thought of that. Simple and useful and a bit more elegant than having a phone output file that I manually `touch`.
Re: Makefiles for web work
#55Earlier quoted context omitted.
Because I wanted the title of my blog posts to match the file name, so I didn't have to remember which markdown file was which post.
Which sounds cool and all, except I bet the URL doesn't have a space character in it, right? And so, now you have a weird mismatch between the files on disk and the site structure.
No, the filename was a sort of composite key.
"yymmdd Name of Article.md"
URL became yymmdd. Name of Article let me know where to find the article at a glance.
Re: Makefiles for web work
#56Earlier quoted context omitted.
That's specifically the gain here, you don't need to keep learning new build tools or language-specific tools. Make works for all languages, all kinds of projects, has been around since forever and is not going away. It's the only build tool you need to learn.
`just` does the same but better, is much quicker to learn (we're talking literal 5-10 minutes), and doesn't have decades of weird syntax baggage.
By the time its close to makes popularity, it will.
Re: Makefiles for web work
#57Make becomes a pretty terrible tool at a fairly low level of complexity. I would never choose it voluntarily to build things.
Yeah, think of how programming languages invent and reinvent stuff to handle the interaction with Make and native libraries, how we have generators of generators of Makefiles... Heck, even Docker's use case is mostly because of the living hell that is C stuff.
Yeah the absurdity of autoconf tooling is enough evidence by itself
Re: Makefiles for web work
#58Before a couple of years ago, I had never written a Makefile in my life.
I ended up using Make after experiencing web project builder merry-go-round du jour of Grunt, Gulp, npm/yarn scripts, WebPack, etc.
Of course I had read all of the Make FUD… but like almost all things in computing (Vim vs. Emacs, tabs vs. spaces, Mac vs. Windows) you can't take it too seriously.
For me, similarly to when I went through several editors before I discovered Vim, Make has been around long enough and people have used it to address the hairiest build/dependency issues that many of the new tools have yet to address.
Let me address a few common issues.
IMHO the syntax isn't that bad. Like almost any programming language, you can write a clean, well-documented Makefile following best practices or you can slap something together with no planning and have an indecipherable page of junk.
And like many languages, many folks never learn to write Makefiles properly. I get it—most Makefiles in the wild are close to unreadable and are mostly undocumented.
And because Make has been around since the '70s, there's lots of hard-earned wisdom in blog posts and forums readily available going back decades.
O’Reilly's book "Managing Projects with GNU Make" (3rd edition) does a great job at getting someone up and running with Make. And the online documentation [1] is also quite good.
But the most important thing is I'm much more productive using Make instead of messing around with the various JavaScript build tools and their plugins. It's easy to integrate JavaScript, command line, Ruby, etc. tools with Make to get my projects built, linted, tested, packaged and deployed.
And having native support for Make in Vim/Neovim [2] is just the cherry on top. And it's still under active development [3] with bug fixes and new features.
Perhaps the best thing about Make: there's no dependency graph/build web project issue it can't handle. Writing clean, readable and well-documented may take a little more effort but it's worth it IMHO.
[1]: https://www.gnu.org/software/make/