Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Naming isn’t consistent with what make does and why it’s called Makefile.

Makefile is for make, which “makes files”.

You don’t “task files”

*file in general is wrong. Of course it’s a file



sort by: page size:

> Taskfile is just a dialect of YAML format with a specific syntax

One of the few formats in common use that's actually worse than Makefile, plus you need to go and find another binary to run the thing.


If you're using GNU make, as the author appears to be doing, makefiles should be named GNUmakefile instead of Makefile so as to not confuse the user or the tools by conflating GNU make with BSD make or other make dialects.

If you don't know what's wrong with make, just use make. But it probably means you probably don't USE make.

If your Makefiles look like this:

    build:
       go build -o dist/app
You might as well just use make, it's fine. It's less fine when you want to avoid rebuilding if sources didn't change, or if you want to use environment variables, maybe from a dotenv file, or if you want to do conditions (like adding a debug flag to a build command if a make variable is set), or if you need to use make incantations (hoping they'll work with both BSD Make and GNU Make), then a Taskfile might help solving some issues, including legibility.

Correction:

> Taskfile: It’s PHONY Makefile in Yaml


> makefiles are essentially fancy bash scripts with significant white space and additional make-related syntax.

Make is a functional programming language. For example, variables are actually lambdas.


I wanted to see what was wrong with Makefile and how Taskfile solved the issue, but the post doesn't explain; it's more a tutorial on how to use Taskfile. If the author reads this, I think we'd love to know what's wrong with make.

Also, a lot of those look like artificial complexity over a shell script sourcing another one containing only variables export, and running the required scripts.


> Most (all?) of your Makefile targets don't represent actual files to 'make'.

> You're using make to run a bunch of tasks, including where tasks may depend on other tasks having been run before.

And the cool thing is....it works for both!

It can represent an actual file (e.g. a compiled binary) or abstract result (e.g., a successful test).


> Makefiles are simply a declarative way to transform one file (or series of files) into another.

Tab echo it certainly is not greater than side_effect.txt.


It is written for Linux, changing the Makefile is not going to change this.

Files with spaces in the name are just a bad idea anyhow, Make is just helping out by making the problem more explicit.

> ...idempotent, or at least stateless...

Even for a Makefile, "start", "test", "install" are likely to be phony (and not literally refer to files with those names).

The execution of a "start" task defers the role of "has it already been done" to other places.

One way of describing "task runner" is "nicer UX for .phony targets".


> Make(1) is basically gnu make today

It is not on a number of platforms that enjoy popular usage.

> In technical terms, it is easier to rename BSDmakefiles rather than millions of projects out there.

GNU is not the standard. Generally it's a superset of it; if so, then it should have the onus of the nonstandard name.


We must be using a different definition of simple. I've never seen a simple makefile.

> You need to create a makefile to tell make what to do.

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.


make looks for [Mm]akefile if you run it with no arguments, but here it's being run recursively (or included). On OSX, filenames are case-insensitive, which could be a possible reason why it works for some people. On Linux, filenames are case sensitive.

Which is pretty ridiculous. Convention dictates that people use Makefile so that's the file people read and edit, yet the make utility reads makefile first by default. Including both is a great way to confuse users.

It is a strange feature but it does have a good underlying idea.

Why would having two functions, named makeFile and make_file in the same program ever be a good idea?

Think of it as less of a language syntax feature and more of a code style enforcement paradigm.

Good lsp support makes it mostly fine imo.


Makefiles have some glaring issues that can't be easily fixed.

The big one is that they break if there are spaces in file or directory names.

Sure, you can argue spaces are bad practice. But they are common on OS X and windows. It's a little silly to use a build system that doesn't support them.


Yeah this is my pet peeve about how people use Makefiles. Make is supposed to be a dependency-driven "dataflow" language, but over time it's evolved into something like shell. And people tend to use it like shell.

The most glaring example is .PHONY targets, which are a hack and should just be shell functions. In 'make <foo>', <foo> should be data, not code. 'make test' doesn't make sense, but 'make bin/myprog' does.

I posted this link in another comment showing how Make, Shell, and Awk overlap:

http://www.oilshell.org/blog/2016/11/14.html

Here are some more comments on Make's confused execution model. It's sort of functional/dataflow and sort of not. In practice you end up "stepping through" an imperative program rather than reasoning about inputs and outputs like in a functional program.

https://news.ycombinator.com/item?id=14840696

And at the end of this post, I talk a bit more about the functional model:

http://www.oilshell.org/blog/2017/05/31.html

next

Legal | privacy