161–170 of 525 posts
Tangential, but I cringe everytime I see the word "transpiler". A compiler is a compiler is a compiler. Previous discussion on this: https://news.ycombinator.com/item?id=15154994
Babel is a JavaScript compiler.
Earlier quoted context omitted.
I did not use Make at this time (I wasn't alive!), but it seems that you'd have to declare dependencies too. How did you determine if it was "old"?
"If a line begins at character 0, that is a list of files whose timestamps should be checked" The list of files would be the declared dependencies.
Earlier quoted context omitted.
> If only whoever authored Make 40 years ago Make was created by Stuart Feldman at Bell Labs in 1976. The fact that it is still in use in any form and still being discussed here is a testament to what an amazingly good job he did at the time. Whether it is the right tool for any given modern use case is up to the people who decide to use it or pass it by. I still work with almost daily, and it's in wide use by backen…
Look at the git makefile: https://github.com/git/git/blob/master/Makefile You know what you have to do to build git? Type make. It's amazing.
Earlier quoted context omitted.
Fun fact: your Makefile above is redundant. You can delete it entirely, and the implicit rules you're using here continue to work just fine.
Yeah make foo.c Should just work. No makefile needed.
Earlier quoted context omitted.
The nice thing about C is that it's a great cross-platform assembly language. I wouldn't call its syntax good or bad.
Exactly. If C hadn't been invented then someone would have invented it later under a different name. Because it's obvious people need a minimalistic portable assembler.
History is re-written by winners as usual.
I have used make for years and am very familiar with it. My two major complaints are: 1. The assumptions that it makes. Everything in and out are files (phony files notwithstanding). It is hard and painful if you want outputs to rely on and rebuild from configuration in the makefile itself. It's not impossible to implement, but it's difficult to precisely implement it: often times I've seen systems that just rebuild…
Earlier quoted context omitted.
Maybe I'm in the minority, but I've always found its syntax to be quite nice (though admittedly a departure from most modern languages). Then again, I find using JSON or not-quite-ruby to configure a build incredibly bizarre and confusing, so I guess I'm just set in my ways... In all seriousness, what's wrong with it? Significant tabs aren't great, but I feel like that's a relatively minor wart. The simple things are…
"In all seriousness, what's wrong with it?" 1. Claiming a rule makes a target, but then fails to make that target, ought to be a runtime fatal error in the makefile. I can hardly even guess at how much time this one change alone would have saved people. 2. String concatenation as the fundamental composition method is a cute hack for the 1970s... no sarcasm, it really is... but there's better known ways to make "templ…
Anyone here uses makefiles for anything other than compilation and build? One can use it to add some level of concurrency to shell scripts.
I think the reason make is both so controversial and also long-lived is that despite how everyone thinks of it, it isn't really a build tool. It actually doesn't know anything at all about how to build C, C++, or any other kind of code. (I know this is obvious to those of us that know make, but I often get the impression that a lot of people think of make as gradle or maven for C, which it really isn't.) It's really…
> It's really a workflow automation tool, That's true. > and the UX for that is actually pretty close to what you would want. That is so not true. Make has deeply woven into it the assumption that the product of workflows are files, and that the way you can tell the state of a file is by its last modification date. That's often true for builds (which is why make works reasonably well for builds), but often not true f…
I've always wondered whether Make would be seen as less of a grudging necessity, and more of an elegant panacea, if operating systems had gone the route of Plan 9, where everything is—symbolically—a file, even if it's not a file in the sense of "a byte-stream persisted on disk."
Or, to put that another way: have you ever considered writing a FUSE filesystem to expose workflow inputs as readable files, and expect outputs as file creation/write calls—and then just throw Make at that?
Earlier quoted context omitted.
Maybe I'm in the minority, but I've always found its syntax to be quite nice (though admittedly a departure from most modern languages). Then again, I find using JSON or not-quite-ruby to configure a build incredibly bizarre and confusing, so I guess I'm just set in my ways... In all seriousness, what's wrong with it? Significant tabs aren't great, but I feel like that's a relatively minor wart. The simple things are…
I've been writing Makefiles regularly for maybe 15 years and I always end up on this page every time I need to write a new one: https://www.gnu.org/software/make/manual/html_node/Automatic... $ $* $^ ... Not particularly explicit. You also have the very useful substitution rules, like $(SRC:.c=.o) which are probably more arcane than they ought to be. You can make similar complaints about POSIX shell syntax but at lea…
I use
$(patsubst %.c,%.o,$(SRC))