nice: friendly but also succinct.
how many people are using systems like cmake (or worse) who would be fine with just make (used right)?
Using Make – writing less Makefile
61–70 of 200 posts
Re: Using Make – writing less Makefile
#62Nice to see some love for make.
Sure, make syntax sucks. It's arcane and hard to google much of what is going on. (Shower thought... a tool that lets you view a Makefile, giving explanatory tooltips for syntax elements would be great).
But make is widespread, ancient and eternal. It isn't going anywhere, despite decades of new tools trying to take its place. It does many jobs relatively well.
I'd go so far as to say that the platonic ideal of development is:
make # Build the project
make install # Install the project
make clean # Clean the project build dir(s)
and whatever new tool you use to actually build things should live behind make. You should have a really good reason to deviate from this. It's approachable and familiar to most devs(well, ok, older C/C++ devs). Sure, write your own custom tool that builds everything in a chroot jail or docker container, has sub tools for installing, running tests, etc... but please, put it behind a make frontend.
Re: Using Make – writing less Makefile
#63If you're looking to an alternative, you could take a look at Task:
Re: Using Make – writing less Makefile
#64Quasi-tangent: I was once hit by a coworker doing first code review on a new repo with "hmm...I'm not familiar with using Makefiles as a project management tool. So something something [don't remember] we should replace that." It struck me as weird because I don't see `make` as a build tool so much as automating shell script snippets you would/could type at the command line. From that POV I conceptually see Makefiles…
Your coworker's experience is more principled: Make is a mediocre tool for executing commands. It wasn't ever designed for that. Although it is pretty common to see what you are mentioning in projects because it doesn't require installing a dependency. For a repo where an easy to install (single binary) dependency is a non-issue, consider using just. [1] You get `just -l` where you can see all the command available,…
This looks really nice. But then should `j` alias to `just` or to `jobs`? Non-starter. /s
Re: Using Make – writing less Makefile
#65Earlier quoted context omitted.
I admittedly don't have a ton of experience with make, but what's the point of doing this vs just throwing the compile commands in a shell script?
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
Re: Using Make – writing less Makefile
#66Earlier quoted context omitted.
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…
Globbing means that the directory has to be scanned on every build Once you start getting to multiple directories and recursive scans, the build time begins to grow enormously and usually unexpectedly. Not a problem at all for small or even medium size projects on a fast machine. But once you start building very large projects with multiple sub-projects, it generally slows the machine to a crawl on every build.
When the project is so big that this is a problem, you can make an additional make target, e.g. "make file_lists" that would use globbing and store the lists into a file that will be used by any other make commands.
The bigger a project is, the more important is to use only globbing and never write explicitly any file name lists.
However, I believe that this, the slowness of globbing for big directories, might be a strictly Windows-specific problem, if it exists. At least on Linux and with XFS (which has B-tree directories) I have never seen globbing to take any noticeable time, even on directories with ten thousand files or more, where it still appears to be instantaneous at the human reaction time scale.
There is no reason to ever do recursive scans. All the directories with source files of a project must be scanned to search for any source files located there, but only once.
Re: Using Make – writing less Makefile
#67Nice to see some love for make. Sure, make syntax sucks. It's arcane and hard to google much of what is going on. (Shower thought... a tool that lets you view a Makefile, giving explanatory tooltips for syntax elements would be great). But make is widespread, ancient and eternal. It isn't going anywhere, despite decades of new tools trying to take its place. It does many jobs relatively well. I'd go so far as to say…
> the platonic ideal of development is:
> make # Build the project
> make install # Install the project
> make clean # Clean the project build dir(s)
IMO, that last step of cleaning is very not platonic ideal. However... maybe a reality of incremental development?
The first step for me in a lot of cases is just trying a project to see if it's worth my time, typically that would just have been:
cd /tmp git clone http://foo/some/project.git cd project # build steps, perhaps in a good case your make example above, a dockerfile, or nix flake
These days though I'm ecstatic when I see a Nix flake because I can reduce that to:
nix run github:some/project
nix develop github:some/project
cd /tmp
unpackPhase
genericBuild
I guess all of the above is to try and express my different idea of platonic ideal here and how Nix gives it to me (and could perhaps to you, for a cost).
Re: Using Make – writing less Makefile
#68If you're looking to an alternative, you could take a look at Task: https://taskfile.dev/ https://github.com/go-task/task
+1 to this recommendation. Everyone likes to point to ‘just’ as a makefile replacement, but having tried both I slightly prefer Task.
Re: Using Make – writing less Makefile
#69With 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…
Using these and other similar features of GNU make it is possible to write a generic Makefile that works for any software project. It appears that almost nobody reads the manual of GNU make, despite the fact that it is extremely instructive. I have read the GNU make manual once, about 25 years ago. Then I have written a set of small Makefiles that I have used in all my software projects forever, until now, with only…
i have a couple of old blog articles that cover the basics of writing a generic makefile for c++ here: https://latedev.wordpress.com/2014/11/08/generic-makefiles-w...
Re: Using Make – writing less Makefile
#70Is there any reason to use make over ninja and gn?
I'm a seasoned developer for the past 15-ish years and I haven't heard of ninja or gn before. I tried typing them in my command line (macos 12.4) and I would need to install them to use them. I was taught make in CS101 in college and the majority of other people's projects I've looked at use it. So the advantage is ubiquity and familiarity. Which can be useful if your code base is going to have a large number of peop…
Ninja was super easy to pick up even after using make for some time (10+ years). GN is just a ninja generator that is optional.