Talk:Makefile

if [ -f $$file ]; then rm $$file; fi;

what about using rm -f, or $(RM) which is by default defined as rm -f ?

Also, are you very sure you can mark an explanation of your own makefile as a tutorial for makefiles? It seems quite arrogant.

-- Candy

The "mark an explanation of your own makefile as a tutorial for makefiles" does seem a little weird. Maybe you just got that strange naming convention and programmers block I get sometimes. .. maybe all the time. Look I am doing it now. "Makefile: Tips And Tricks". <Have mercy on me..>

-- kmcguire 10:40 AM CST 11 March 2007

Everything is relative, so is arrogance. A practical example may be a good starting point, even if it is your own code. As long as it serves its purpose and people learn from it, why should we care?. You have an alternative? ;) - Combuster 03:05, 12 March 2007 (CDT)

Sorry for taking so long to reply, I'm not a "regular" to the new Wiki (yet?). Candy, you are of course right about the $(RM) implicit variable. The "if"-wrapper is being done to keep the Makefile quiet even if a file from the list does not exist (which is not, in fact, an error, and thus shouldn't bother the user). I know I had problems with "only" rm -f to this end, but would have to do some testing to give an exact explanation. As for the "arrogance" part... you can't write "the" tutorial about makefiles, because make is far too diverse. You can use them to run everything and the kitchen sink. I thought the PDCLib Makefile - being AFAIK correct, non-trivial, and yet not overly long / complex - would be a good example for others to learn a few tricks about Makefiles, especially the dependency handling and non-recursiveness. I shall make the wording a bit more general, and add a note that this is meant as a starting-point, with feedback / requests for extensions being very welcome. Sorry if it sounded too arrogant. Solar 03:02, 28 March 2007 (CDT)

Sorry but right now I can't be bothered to do this. I have more or less dropped osdev.org completely, and am spending my time on other projects. I might return later, but for now feel free to rewrite this any way you like. Solar 23:31, 22 April 2007 (CDT)

Looks better to me. I especially liked the fact that I found a neat section on extracting the TODO:s from a source tree which I just never have thought about doing.

--Kevin 18:22, 29 April 2007 (CDT)

I did a rework today, including some explanation on why I used the actual PDCLib Makefile instead of giving general tipps. I hope you like it. Solar 04:20, 21 January 2008 (CST)

$(RM) wildcarding

-@for file in $(OBJFILES) $(DEPFILES) $(TSTFILES) $(REGFILES) pdclib.a pdclib.tgz; do if [ -f $$file ]; then rm $$file; fi; done

Wow, that is ugly, and IMO needlessly complicated. A much better rule would be:

@$(RM) $(wildcard $(OBJFILES) $(DEPFILES) $(TSTFILES) $(REGFILES) pdclib.a pdclib.tgz)

The wildcard function returns a list of only the files that exist, so the if statement and for loop are no longer necessary. Likewise, the - to ignore failures from $(RM) is unneccessary because all files are guaranteed to exist. Although if you don't have permission to delete them, then a failure will stop any other rules that may be in that target from being run, but that's correct bahavior anyway. --quok 07:05, 26 August 2008 (UTC)

Very nice. -- Solar 08:43, 26 August 2008 (UTC)

Recursive Make

I'm not an expert in makefiles and I do understand the overhead inolved in recursive invocations of "make". However, parallel builds are impossible without recursivity as far as I can tell. Feel free to correct me.--Love4boobies 00:44, 10 April 2010 (UTC)

Make will build anything in parallel, as long as you use -j[N]. Nedbrek 10:47, 12 April 2010 (UTC)

And it's actually the other way around - recursive Makefiles are always in danger of not representing the whole dependency graph, and the more processes you run in parallel, the higher the chances to break something. Monolithic Makefiles don't suffer from this problem.

The parallelity doesn't come from multiple Makefiles being executed in parallel, but in multiple rules being run. (You have 100 .c files to be turned into .o files, so you can run 100 compiler processes if you feel like it.) -- Solar 14:26, 13 April 2010 (UTC)

You are right, of course. Thank you for clearing up how parallel building actually works, Solar.--Love4boobies 09:22, 14 April 2010 (UTC)

Extended todolist...

I disagree with Virtlink's edit [1]. Indeed in the PDCLib makefile that was the "template" for this article, I have two different targets, one for TODO: comments and one for FIXME: comments, as the two represent very different levels of urgency; I only presented one of the two as I felt it would be trivial to adapt this to personal choice. You usually don't want TODOs in a FIXME-list, and vice versa. The -F option may make the grep faster, but I feel it's a bit non-KISS. And while we're at it printing file names, why not line numbers to go? Suggestion:

todolist:
-@for file in $(ALLFILES); do grep -Hn TODO $$file; done; true

This will print a list of all TODO comments from my files, complete with file name and line number. Nice to be remembered what's still missing before you do a release.

'fgrep' seems simple enough, and has advantages, especially when you have a big project to build. On the other hand, '-Hn' (or '-H' for that matter) seems also a bit non-KISS to me, however it may be useful. And it is not that trivial to add another keyword, because you need the '-e' switch for that. To me (any possibly to you too), FIXME's are more urgent than TODO's (in the spirit of 'what's missing before you do a release') so maybe we should use those in the example instead. I suggest the following (or with 'fixme' replaced by 'todo'): Virtlink 16:03, 20 August 2008 (UTC)

fixmelist:
    -@for file in $(ALLFILES); do fgrep -Hn -e FIXME $$file; done; true

This will grep all those FIXME comments from the files and display them in the terminal. It's nice to be remembered of what's still missing before you do a release. To add another keyword, just add another -e keyword. Don't forget to add fixmelist to your .PHONY list.

Bug in Dependencies, pt. 3?

Should

   %.o: %.c Makefile
           @$(CC) $(CFLAGS) -DNDEBUG -MMD -MP -MT "$*.d $*.t" -g -std=c99 -I./includes -I./internals -c $< -o $@

not be

   %.o: %.c Makefile
           @$(CC) $(CFLAGS) -DNDEBUG -MMD -MP -MT "$*.o $*.t" -g -std=c99 -I./includes -I./internals -c $< -o $@

instead? --Mikeroz 01:13, 1 August 2009 (UTC)

Not quite. The $*.d is needed to recreate the dependency file itself. But you are absolutely right that the $*.o was missing. Funny that no-one else pointed this out (and a shame that I didn't figure this one out earlier, especially since I've got a corresponding bug sitting in my PDCLib tracker for ages...). -- Solar 14:27, 19 June 2010 (UTC)