On Sun, 2022-09-04, Dario Niedermann wrote:
While writing a makefile for a program of my own, it's occurred to me
that I've always seen makefiles with just "phony" install targets
(even make's original manual from Bell Labs does it that way).
But I think I've never seen the actual destination files used as targets.
So I've tried to do that in my makefile:
-----
$(bindir)/prog: prog
install -D prog $@
$(mandir)/prog.1.gz: prog.1.gz
install -D prog.1.gz $@
install: $(bindir)/prog $(mandir)/prog.1.gz
-----
Aside from looking like a more truthful representation of what really happens, this has the advantage that make will say 'nothing to be done
for install' if you try to install files that are older or equal to what
you have already installed.
But are there any disadvantages I'm not considering?
This may not be a direct answer, but:
The way I see it, "make install" is a harmless and convenient abuse of
make(1). I want it to install unconditionally, because
- The destination is outside the "project" and can be affected by
things outside it. You may have ~/prog-1.2/ and ~/prog-1.3/ and you
may be building in and installing from both directories.
- Ownership and permissions matter for the destination files.
Make doesn't care about such things.
- When I want to install something, I think it through first. If I
want it installed, I don't care what's there already. (And if I
really want control, I probably want to generate a package (RPM,
.deb) and install that one.)
So I accept that the "install", "clean", "check" targets (and maybe a
few more) are odd.
/Jörgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)