I am quite certain to have used such kind of tooling during 1990's, with ads on The C/C++ Users Journal and Dr. Dobbs developer magazines.
b0a04gl 36 minutes ago [-]
some Makefiles use indents or var placement as semantic cues. if a tool rewrites them mechanically, it might clean things while killing meaning. is structural correctness enough, or do we need formatters that preserve human context too?
jchw 11 minutes ago [-]
That doesn't sound any different than it is for any other programming language, but many people prefer automatic formatting anyways.
iib 16 minutes ago [-]
Ideally, we'd have linters that preserve the human context as well. But human context may be too ambiguous and high variance enough that it can be impractical.
It's hard to say what's intent and what not, maybe linters with many custom rules would work best.
It really doesn’t have to be complicated for it to be useful. Plenty thanks for sharing this.
s4i 5 hours ago [-]
Does this support inline ignoring specific rules with some syntax? Couldn’t find this from the README. Would be good to have as an escape hatch.
1oooqooq 3 hours ago [-]
ewwww. consolidated phony lines. everyone knows these should be right before each rule declaration.
Crier1002 6 hours ago [-]
ive always wanted this. im going to give it a go!
does this happen to support IDE like vscode?
antonhag 4 hours ago [-]
From the readme:
VSCode Extension
1. Open VSCode
2. Go to Extensions (Ctrl+Shift+X)
3. Search for "mbake Makefile Formatter"
4. Click Install
Crier1002 2 hours ago [-]
thanks! apologies i was on mobile and missed this. im excited to try it out
waqar144 5 hours ago [-]
Uh, why Python?
legends2k 4 hours ago [-]
Why not Python? I primarily program in C++ but I see it as a decent choice as Python is available in almost all recent machines. Of course Windows is a notable exception but given it's a tool for developers I guess Python should be present.
IshKebab 4 hours ago [-]
1. Terrible performance.
2. Terrible installation UX.
The number of issues we've had with pre-commit because it's written in Python and Python tooling breaks constantly...
In fairness, the latter point may be finally solved by using `uv` and `uv tool install`. Performance is still a major issue though. Yamllint is easily the slowest linter we use.
(I'm tempted to try rewriting it in Rust with AI.)
viraptor 2 hours ago [-]
It definitely is a problem when the tool you're going to use a few times a week takes an extra hundred milliseconds compared to a native solution. Especially when you need to process huge data files like hand crafted makefiles. I can totally feel your pain - extra effort would've been made to avoid that at the cost of development speed. /s
justinrubek 18 minutes ago [-]
I find that writing anything substantially complex in python sacrifices the development speed. That isn't its strong suit. It's that a lot of people want to write their code in it by preference.
smusamashah 2 hours ago [-]
Terrible portability across platforms specially with dependencies.
exe34 5 hours ago [-]
Presumably because the author is comfortable with python and it is easy to do string manipulation with.
johnisgood 3 hours ago [-]
Perl is much faster than Python, and it is especially good for string manipulation. Thus, I would have chosen Perl.
a2128 2 hours ago [-]
I would've chosen Java because it's faster than Python and is good for string manipulation. My cousin would've chosen Brainfuck because he's really good at it. Alas, this discussion is useless because none of us are the one who spent the effort to write the Makefile formatter and linter, we can only bikeshed all day about what decisions we would've taken
johnisgood 37 minutes ago [-]
For the 100th time, I was responding to "[...] python and it is easy to do string manipulation with.". Perl is way better to do string processing in than Java, too, FWIW.
My comment has absolutely nothing to do with this project or its author, nor the language he has chosen. See the other comments in this thread.
WJW 2 hours ago [-]
Almost everybody knows python these days, almost nobody knows Perl. It's not weird that OP chose a language they already knew.
johnisgood 2 hours ago [-]
I am not saying it is weird, I was just responding to parent with regarding to "string manipulation", and someone mentioned "performance", so I stated two facts about Perl.
I do not care whether or not this project is written in Python. Sure, he chose Python because he is more familiar with it. That is fair enough to me.
elteto 17 minutes ago [-]
Perl is absolutely not faster than Python, not even for regexes.
exe34 3 hours ago [-]
Would you be willing to share the link to your repo?
johnisgood 2 hours ago [-]
I have not written a Makefile formatter and linker in any languages.
exe34 2 hours ago [-]
Yes, I thought so. It's much easier to criticize than to create.
johnisgood 2 hours ago [-]
It does not invalidate anything I have said, and this reasoning of yours is so flawed.
For example: I thought this or that music or movie sucked. I do not need to know how to make a song or a movie to be able to criticize it, let alone have one in a similar vain, same with books. I can criticize a book, or an article, without having written one myself on related topics.
All that said, where did I criticize? I did not criticize anything, at all.
I stated facts. Perl is indeed faster than Python, and Perl was indeed made with string manipulation in mind. I made no comment about this project or its author, thus, it was not a criticism of any sort.
exe34 2 hours ago [-]
Do you regularly offer your directorial opinions to movie makers and singers? Or is it just programmers?
johnisgood 44 minutes ago [-]
I do not care about movie makers and singers in general, and for the most part I do not have direct contact with them, so it would be futile to offer any advice. I did offer advice to a couple of singers before though. What is your point besides being unnecessarily defensive over two simple, stated facts? As I said, it was not a criticism of the author or the project, it was a response to your comment. Since this is going to lead nowhere, I am going to stop responding to this thread.
x3n0ph3n3 6 hours ago [-]
I don't understand why people like make so much. Interacting with CLI tools using only env vars as arguments is cartoonishly bad dev experience.
zelphirkalt 5 hours ago [-]
Make allows you to specify dependencies for you targets, which are also targets. As such you do not need to rely on brittle string concatenation approaches. It is a tool build for this.
I personally like going to a project folder and run "make run", no matter what language or setup I have, to run the project. It enables me to unify access to projects.
I also take great care to make these runs reproducible, using lock files and other things of the ecosystems I am using, whenever possible. I work on another machine? git clone, make run. Or perhaps git clone, make init, make run.
georgyo 5 hours ago [-]
I'm not so sure most people would agree with you. Though I think plenty would.
I dare say that developers like environment variables more than before. Consider that Docker images, and hence Helm charts, are entirely controlled via environment variables. These very popular dev tools suffer from the same problem of having near-zero easy discoverability of what those environment variables might be. Yet they are very popular.
But I don't think Make usually uses all that many environment variables. You're usually specifying build targets as the command line arguments. Automake and autogen usually generate these makefiles with everything hard-coded.
Also, it makes it very easy to get started with, and it is universally available. Makes it very easy to like.
cerved 4 hours ago [-]
I like it because it's language and tooling agnostic, declarative, fast and ubiquitous.
Where it's less great is complicated recipes and debugging
xigoi 39 minutes ago [-]
Make is not language agnostic; it has implicit rules for compiling C.
pheggs 14 minutes ago [-]
it also has implicit rules for other languages, why would that make it non-agnostic?
danlitt 4 hours ago [-]
Make is in POSIX, so it's generally available. Same reason people write shell scripts (even if the scripts are not generally POSIX-only).
bshacklett 51 minutes ago [-]
Unless your company forces you to use Windows, which is still much more common than many would like to admit. And yes, WSL exists, but in my experience, if a company is unwilling to allow macOS, there’s a good chance they either don’t allow enabling HyperV, or the security software they use is such garbage that it results in a HyperV enabled system being effectively unusable.
motorest 2 hours ago [-]
> Interacting with CLI tools using only env vars as arguments is cartoonishly bad dev experience.
Make excels at what it's design to do: specify a configurable DAG of tasks that generate artifacts, execute them, and automatically determine which subgraph requires updates and which can be skipped by reusing their artifacts.
I wonder: which tool do you believe does this better than Make?
But the Internet’s make mind-share means you still have to know make.
Edit: and make lets you use make to essentially run scripts/utils. People love to abuse make for that. Can’t do that with tup.
aDyslecticCrow 1 hours ago [-]
Abuse? Runnig linters, code analysers, configuration tools, template engines, spellcheckers, pulling dependencies, building dependencies with different build systems.
Sufficiently complex project need to invole alot of wierd extra scripts, and if a build system cannot fulfil it... the n it needs to be wrapped in a complex bash script anyway.
I mean there's really not much difference between "VAR=val make x" and "make x VAR=val" now is there?
marginalia_nu 5 hours ago [-]
Syntactically? No. Semantically? Yes.
lmz 2 hours ago [-]
I'm guessing the syntax was the part the poster was complaining about when they complained about the "dev experience".
marginalia_nu 27 minutes ago [-]
Dunno, there are other aspects of environment variables that deteriorate the dev experience. They're very conducive to spooky action at a distance, since they're silently being passed along from parent-process to child-process (except when they aren't).
They can cause a lot of annoying bugs, and sometimes it's hard to track down where they are coming from (especially when dealing with stuff running in containers).
PhilipRoman 4 hours ago [-]
You don't have to write Make invocations by hand... It's just a tool that can be called from any editor or IDE (or by automatic file watchers). Environment variables aren't really relevant to Make either, unless you really want to misuse it as a command runner.
aboardRat4 3 hours ago [-]
Because make is a prolog in disguise.
hiAndrewQuinn 5 hours ago [-]
I often prefer to work in in extremis environments where there is no internet access, and hence, no easy way to get ahold of make; it's given me a bad habit of just waiting a build.bash script to do what make does most of the time. I haven't really found myself missing it that much.
0points 5 hours ago [-]
If you can install bash on your airgapped dev box, why wouldn't you install make on it? Make is part of the core dev environment on just about every disto under the sun.
M0r13n 5 hours ago [-]
I am confused, because this means that you won't be able to install anything. No compiler, no 3rd party libraries and no text editor that isn't preinstalled
globular-toast 5 hours ago [-]
It's 80% of what you want and it's installed everywhere.
You could go for something closer to exactly what you want, but now you've got an extra set up step for devs and something else for people to learn if they want to change it.
I would say if you're looking for cli args then you shouldn't be using any wrapper like make at all. Just call the underlying tool directly. Make is for doing big high level things in the standard way, nowadays quite often in CI pipelines.
zelphirkalt 5 hours ago [-]
Yep, that's how I used it on the job before. "make test" would run tests locally and in CI pipeline, keeping the CI file refreshingly short at that point.
6 hours ago [-]
gjvc 2 hours ago [-]
you don't do it naked, you write and use wrapper scripts to make it ergonomic
https://aur.archlinux.org/packages/python-bake-git
It's hard to say what's intent and what not, maybe linters with many custom rules would work best.
does this happen to support IDE like vscode?
2. Terrible installation UX.
The number of issues we've had with pre-commit because it's written in Python and Python tooling breaks constantly...
In fairness, the latter point may be finally solved by using `uv` and `uv tool install`. Performance is still a major issue though. Yamllint is easily the slowest linter we use.
(I'm tempted to try rewriting it in Rust with AI.)
My comment has absolutely nothing to do with this project or its author, nor the language he has chosen. See the other comments in this thread.
I do not care whether or not this project is written in Python. Sure, he chose Python because he is more familiar with it. That is fair enough to me.
For example: I thought this or that music or movie sucked. I do not need to know how to make a song or a movie to be able to criticize it, let alone have one in a similar vain, same with books. I can criticize a book, or an article, without having written one myself on related topics.
All that said, where did I criticize? I did not criticize anything, at all.
I stated facts. Perl is indeed faster than Python, and Perl was indeed made with string manipulation in mind. I made no comment about this project or its author, thus, it was not a criticism of any sort.
I personally like going to a project folder and run "make run", no matter what language or setup I have, to run the project. It enables me to unify access to projects.
I also take great care to make these runs reproducible, using lock files and other things of the ecosystems I am using, whenever possible. I work on another machine? git clone, make run. Or perhaps git clone, make init, make run.
I dare say that developers like environment variables more than before. Consider that Docker images, and hence Helm charts, are entirely controlled via environment variables. These very popular dev tools suffer from the same problem of having near-zero easy discoverability of what those environment variables might be. Yet they are very popular.
But I don't think Make usually uses all that many environment variables. You're usually specifying build targets as the command line arguments. Automake and autogen usually generate these makefiles with everything hard-coded.
Also, it makes it very easy to get started with, and it is universally available. Makes it very easy to like.
Where it's less great is complicated recipes and debugging
Make excels at what it's design to do: specify a configurable DAG of tasks that generate artifacts, execute them, and automatically determine which subgraph requires updates and which can be skipped by reusing their artifacts.
I wonder: which tool do you believe does this better than Make?
But the Internet’s make mind-share means you still have to know make.
Edit: and make lets you use make to essentially run scripts/utils. People love to abuse make for that. Can’t do that with tup.
Sufficiently complex project need to invole alot of wierd extra scripts, and if a build system cannot fulfil it... the n it needs to be wrapped in a complex bash script anyway.
They can cause a lot of annoying bugs, and sometimes it's hard to track down where they are coming from (especially when dealing with stuff running in containers).
You could go for something closer to exactly what you want, but now you've got an extra set up step for devs and something else for people to learn if they want to change it.
I would say if you're looking for cli args then you shouldn't be using any wrapper like make at all. Just call the underlying tool directly. Make is for doing big high level things in the standard way, nowadays quite often in CI pipelines.