Hacker News Reader

Comment by Quekid5 | Hacker News Reader

They are simple but very often wrong. It's surprisingly hard to write Makefiles that will actually do the right thing under anything other than "build from scratch" scenarios. (No, I'm not joking. The very existence of the idea of "make clean" is the smoking gun.)

View on HN

I disagree, but I think once a project gets beyond a certain level of complexity you may need to move beyond make. For simple projects though I usually do something like:

    CC=clang
    MODULES=gtk+-3.0 json-glib-1.0
    CFLAGS=-Wall -pedantic --std=gnu17 `pkg-config --cflags $(MODULES)`
    LDLIBS=`pkg-config --libs $(MODULES)`
    HEADERS=*.h
    EXE=app
    
    ALL: $(EXE)

    $(EXE): application.o jsonstuff.o otherstuff.o

    application.o: application.c $(HEADERS)

    jsonstuff.o: jsonstuff.c $(HEADERS)

    otherstuff.o: otherstuff.c $(HEADERS)

    clean:
            rm -f $(EXE) *.o

This isn't perfect as it causes a full project rebuild whenever a header is updated, but I've found it's easier to do this than to try to track header usage in files. Also, failing to rebuild something when a header updates is a quick way to drive yourself crazy in C, it's better to be conservative. It's easy enough that you can write it from memory in a minute or two and pretty flexible. There are no unit tests, no downloading and building of external resources, or anything fancy like that. Just basic make. It does parallelize if you pass -j to make.

Makefile Effect in action...

That's effectively "make clean" just slightly more automated. Btw, what happens if you change CFLAGS? Does anything get compiled if no files have changed?

I use makefiles all the time for my projects; projects that are actually built with something else (ex, gradle, maven, whatever). My makefiles have targets for build, clean, dependencies, and a variety of other things. And they also have inputs (like "NOTEST=true") for altering how they run. And then I use make to actually build the project; so I don't need to remember how the specific build tool for _this_ project (or the one of many build tools in a project) happens to work. It works pretty well.

The idea that git offers a 'clean' command was revelatory to me. Your build system probably shouldn't need to know how to restore your environment to a clean state because your source control should already know what a clean state is.

That's sort essential to serving its purpose, after all.

I haven't yet run into a scenario where there was a clean task that couldn't be accomplished by using flags to git clean, usually -dfx[0]. If someone has an example of something complex enough to require a separate target in the build system, I'm all ears.

[0] git is my Makefile effect program. I do not know it well, and have not invested the time to learn it. This says something about me, got, or both.

The problem with `git clean` is -X vs -x. -x (lowercase) removes EVERYTHING including .env files and other untracked files. -X (uppercase) removes only ignored files, but not untracked files.

If there is a Makefile with a clean target, usually the first thing I do when I start is make it an alias for `git clean -X`.

Usually, you want to keep your untracked files (they are usually experiments, debugging hooks, or whatever).

You are almost certainly right that I was using -X. It's been a while since I had to deal with git.

This. I have no urge to have git "clean" my project, because I'll lose a ton of files I have created locally. Rather, I want the project know what it creates when it builds and have the ability to clean/purge them. It's a never ending source of frustration for me that "gradlew clean" only cleans _some_ stuff, and there's no real "gradlew distclean".

Hmm, I wonder what's the best way™ to, er "locally backup" those files, in such a way that no git-clean invocation will remove them without promoting.

All I can think of are things like periodically copying them to another folder, or give them a different ownership needed for edit/delete, etc.

Unless there's some kind of .gitpreserve feature...

You can have locally ignores files in .git/info/exclude IIRC.

I know there are local-only git settings, but AFAIK ignore-status won't protect files from being removed/overwritten by all possible git commands, it just means they won't be accidentally staged/committed.

make clean is supposed to clean the intermediary files only but keep the actual build targets (typically what you want to install)

You might want .INTERMEDIATE in that case.

That’s why I usually write them from scratch and don’t let them get over 100 lines long at most. Usually they are around 30 with white space.

make clean makes lots of sense but is not even strictly necessary. In the world where all it does is find all the *.o files and deletes them it’s not a bad thing at all.

Reply on news.ycombinator.com