161–170 of 200 posts
Earlier quoted context omitted.
Make will automatically do all the steps, and stop if any one fails. Of course you van do manually, but is much more work.
The irony is that the same argument would work against Make in the description further up vs other build systems like CMake etc. Not to take away from your correct answer of course
Earlier quoted context omitted.
Globbing is possible but unwise. You do want a variable with an explicit list of sources, even while trying to make things as automatic and dynamic as possible.
Why would you want that? In decades of programming in very varied environments I have never compiled any software project otherwise than by using globbing, so that I have never needed to waste time to write the name of any source file in a Makefile. I have never seen any reason to do otherwise. For instance, using special compilation flags for a certain source file, different from the others, is something that I cons…
With gnu make you don't even need OBJs for a simple directory in which all the .c files are compiled: .SECONDEXPANSION foo: $$(patsubst %.c,%.o,$$(wildcard *.c)) $(CC) $(LDFLAGS) $^ $(LDLIBS) -o $@ Admittedly you can end up with short, very general Makefiles that look like they were a Prolog program written in TECO. But the advantage is that they are general so don't need to be fiddled with as your project grows. I m…
> a Prolog program written in TECO I know we don't do general-purpose "I like this" comments on HN, but, as a Christmas treat to myself, I'm just going to say how happy this little sentence fragment makes me.
As it happens I used to program in both Prolog and TECO, in the same period of time but of course not on the same code bases.
Earlier quoted context omitted.
> I spent many hours trying to figure out how to bypass those issues, and I can't remember if I ever succeeded. Might I suggest “got-restore-mtime” for this, upstream in Debian and Ubuntu already. Did you really spend hours on this?
This? https://manpages.org/git-restore-mtime
Earlier quoted context omitted.
Apparently the reasoning behind a bunch of Make’s warts is that by the time Stuart Feldman realized the problem, it already had half a dozen users, and, well, he wasn’t gonna go and break it for them!
I don't see why there couldn't be (even today!) some statement like "require version XYZ", which Make could notice, which would enable new features and nicer syntax. Something like "editions" in Rust, though the idea is much older. For some reason, people prefer to add more layers on top of Make rather than improving the core language and tool. Maybe there's some good reason?
GNU Make has been steadily gaining new functions though. I've been reading the manual again recently and there were a few functions I did not recognize: let and intcmp. The new integer comparison function is particularly notable since people have gone to some rather incredible lengths to implement arithmetic in make:
It's also possible to write native plugins for GNU Make to load at runtime. New functions can be implemented this way. It works just like C extensions for other scripting languages. There's also Guile extension support but unfortunately it doesn't seem to allow new function definitions.
Earlier quoted context omitted.
> I'm a seasoned developer for the past 15-ish years and I haven't heard of ninja or gn before Then you also stopped learning about developments in your field 15 years ago. > I tried typing them in my command line (macos 12.4) and I would need to install them to use them. Ok? And? We don't pre-installed dev tools on consumer operating systems. You won't find valgrind or vcpkg either. > I was taught make in CS101 in c…
No need for personal attacks here, I'm just answering based on my experience.
There's no way to respond other than to point out you've had a very bizarre, isolated 15 years if the only thing you encounter regularly is make. In the one language ecosystem where make is still popular (plain C), it's a minority that only comes in second overall for build tools [1]
[1]: https://www.jetbrains.com/lp/devecosystem-2022/c/#which-proj...
Earlier quoted context omitted.
> Any tool/language that wishes to be generally useful in an OS doesn't want to be built by something that is only available much further up the tree like python. This is a non-priority, an unreal use case. I can't build GCC without a functioning C++ compiler and a fairly sophisticated OS environment and that's fine. Real-world use cases for bootstrapping a build environment from rubbing two sticks together are so ex…
Make exists and is used widely and not because everyone's too inept to understand your points. The "assumption-making" build tools are the unicorns that inevitably cannot dominate because they're not generally applicable. The more they assume the more niche they become.
They already do dominate. In the last bastion where make can be said to be popular (C) make has already lost to CMake and its usage shrinks every year [1]
The situation is moving even faster for C++ [2]
And for literally every other language in the systems programming space (C#, Swift, Rust, D, Go, Zig), make was never a player to begin with.
[1]: https://www.jetbrains.com/lp/devecosystem-2022/c/#which-proj...
[2]: https://www.jetbrains.com/lp/devecosystem-2022/cpp/#Which-pr...
Earlier quoted context omitted.
> Make's core purpose is to execute commands, isn't it? How was it not designed to execute commands? Some people on HN believe that if you use make primarily as a task runner that you're doing it wrong and should use something else. I don't agree. Most users are using multiple aspects of make: as a task runner and as something that handles the dependency graph when building something digital. As a web developer, I us…
What’s the point of using another tool to manage your shell scripts though? Why not just use shell scripts
When you create a Makefile, you're describing a dependency graph of what depends on what and the order tasks need to take to produce a particular set of digital artifacts--you're not writing shell scripts.
Turns out there are all kinds of edge cases and foot guns that make handles for you that you'd otherwise have to deal with if you wrote a bespoke shell script.
Plus make is battle tested and has been around since the dawn of Unix--there's literally no build scenario it can't handle.
I hadn't used make until a few years ago but it's been one of the best investments I've made in my workflow.
Earlier quoted context omitted.
No, no. Make's principal purpose is to put a set of files into a desired state. It can "make" a particular file by invoking a dependent graph of commands that produce that file from other files. It checks timestamps and only run steps where the resulting files are older than some of the (transitive) source files. You can invoke it by naming a named rule, not a file, but the logic will remain. If this is not what you…
I tell people not to use make if there's no need for a dependency graph. Just don't. And do just :-)
Earlier quoted context omitted.
I have a vivid memory of autoconf. I set it up best as I could. Someone ran ./configure. It triggered a new run of autoconf that failed because of mismatching autoconf version. Why it triggered a new run? Because of mtime checks. Why did they say it needed to be rerun? Because git doesn't preserve mtime. I guess it's just assumed that everyone distributes their sources as a tarball. I spent many hours trying to figur…
> I spent many hours trying to figure out how to bypass those issues, and I can't remember if I ever succeeded. Might I suggest “got-restore-mtime” for this, upstream in Debian and Ubuntu already. Did you really spend hours on this?
Also I think it took quite a while to even realize the mtimes were the issue from an error messages, as I was not very knowledgeable about autoconf / automake.