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)

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.