never use makefiles. its not 1975 and we have learned a lot since then
One line you should add to every makefile
81–90 of 99 posts
Re: One line you should add to every makefile
#82print-%: ; @echo $*=$($*) .PHONY: print-% This way the rule continues to work even if such a file suddenly exists in your repo.
No, implicit rules cannot be marked as .PHONY this way. You need to declare an explicit pseudo-target to achieve this. .PHONY: FORCE FORCE: print-%: FORCE ; @echo $*=$($*)
I touch make files rarely enough that whenever I do, I have to re-learn most of what I need to know - and when I see phrases like 'explicit pseudo-target', I ask myself if it really has to be this way (but never have the time to answer myself.)
Re: One line you should add to every makefile
#83Everyone seems to talk about make files for generating complex c projects. What about make files used to store bash commands of medium complexity. In my python projects I have make clean-pyc, make test, for example. In my music folder I can make find-big-dirs, make find-non-mp3, etc
Advantages are it is easy to edit, cat, and the locality of the commands: I don't want to pollute my bashrc with commands that are useful only in a given context.
Re: One line you should add to every makefile
#84Earlier quoted context omitted.
I am old enough to remember when assembly programmers used to use that complaint as a reason not to program in C. And when C programmers would use that complaint as a reason not to program with templates in C++. And when C++ programmers used that complaint as a reason not to program in languages with garbage collection. The truth is that no matter what level you program at, you are depending on a long toolchain that…
Here's the post you were thinking of, be sure to bookmark it this time! :) https://plus.google.com/+JeanBaptisteQueru/posts/dfydM2Cnepe
Thank you, that is the link. :-)
Re: One line you should add to every makefile
#85Earlier quoted context omitted.
I am old enough to remember when assembly programmers used to use that complaint as a reason not to program in C. And when C programmers would use that complaint as a reason not to program with templates in C++. And when C++ programmers used that complaint as a reason not to program in languages with garbage collection. The truth is that no matter what level you program at, you are depending on a long toolchain that…
I interpreted the comment a bit more generously. The admonition wasn't to avoid using higher level tools, but not to try editing the low level output of a high level tool. I prefer writing in C to writing in assembler, but I would never want to modify the assembler produced by a compiler. Similarly, I prefer scheme to C, but I would prefer handwritten C to editing the output of the Chicken-to-C compiler. That comes b…
I've seen cases where the low level output is perfectly reasonable. And other cases where the low level output contains a section explicitly meant so that people can insert into it. And other cases where it is unreasonable.
That said, if you find autogenerated "stuff", that is not evidence you can't work on the project. It is evidence that you need to understand something before doing so.
Re: One line you should add to every makefile
#86Everyone seems to talk about make files for generating complex c projects. What about make files used to store bash commands of medium complexity. In my python projects I have make clean-pyc, make test, for example. In my music folder I can make find-big-dirs, make find-non-mp3, etc Advantages are it is easy to edit, cat, and the locality of the commands: I don't want to pollute my bashrc with commands that are usefu…
I often use make as a task-runner too, which is super useful. In fact, I currently have a makefile that will build and test both the backend (PHP/Hack) and the front end (Browserify, less, etc.). The best part about make is that it handles new languages without issues: if it outputs files, make can handle it.
Re: One line you should add to every makefile
#87never use makefiles. its not 1975 and we have learned a lot since then
examples?
Re: One line you should add to every makefile
#88Earlier quoted context omitted.
It seems every competent programmer makes that mistake at least once in their carreer :)
The mistake of writing your own makefile generator or using perl? My first experience with perl read in all of the files in its directory and output to another file also in the directory, it managed to read in both itself and the output. I accidentally implemented `rm *`.
Heh, I'm currently in the positive phase of my oscillating love-hate relationship with Perl, and acknowledge its right to exist.
No, I was referring to implementing a replacement/frontend to Make.
Re: One line you should add to every makefile
#89Earlier quoted context omitted.
I wrote a god-awful Perl script to gen (and update) Makefiles for me: https://github.com/wspeirs/makemake
It seems every competent programmer makes that mistake at least once in their carreer :)
In my case it wasn't a mistake, it was a university assignment. That was the assignment where I learned (by omission) how important it is to have source control...
Re: One line you should add to every makefile
#90Earlier quoted context omitted.
When I started with make, I copied working files to a safe place, copied from the safe place to a scratch place, tweaked the scratch, got it working, etc., etc. Managing the make file was itself part of managing the project. Then I read and thoroughly grokked the O'Reilly book on make (which some douche stole from my desk; twenty plus years on, I am still bitter about that one... ...don't miss the Tannenbaum OS book…
git rebase I pretty much understand. Make will forever be a mystery to me. Mostly just how after the third or fourth version of it they didn't take a step back and think, "Hey, wait, maybe we should just make a language that spits out a shell file and ditch having it sort of kind of look like a shell file itself."
The point of make is to avoid doing what does not need to be done. Don't recompile binary whose sources didn't change, don't copy file which is already there, and so on. Because those operations add up to hours as the project grows.
If we didn't mind waiting for hours each time we build, then of course, a shell script that does `rm -rf target` then assembles everything from scratch would be significantly more straightforward and readable.