From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Subject: RE: Fileutils 4.0 port and ginstall
Date: Tue, 6 Mar 2001 21:30:06 +0100
Message-ID: <CAEGKOHJKAAFPKOCLHDIAEFDCBAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Pine.LNX.4.10.10103061903500.1749-100000@acp3bf>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> > ok (people probably don't run 'make install' more than once).
> 
> They don't? Hmm... then how could the ever upgrade programs to a new
> version? Or re-install a program's installed  after a minor correction
> to the source?
What I meant was that 'make install' isn't a normal part of the build
process (it's normally run once after a build process completes), so
the fact it keeps remaking one of its targets doesn't matter.  This as
opposed to some build rule depending on a similar construct, where
install's failure to create the expected output could result in a large
portion of the build to be re-run; imagine the install target in my
example was a 'halfway there' marker, where some programs are "installed"
to some part of the build tree, to be used by the next phase of the
build.  If the rules for such a system had dependencies on the target
locations of those programs, the next phase of the build process might
be re-run unnecessarily during each make invocation.

.PHONY: all
all: part2

part1-done: ${buildtooldir}/mytool2 ${buildtooldir}/mytool2
	touch $@

${buildtooldir}/mytool1 ${buildtooldir}/mytool2: ${buildtooldir}/%: %
	install -m 755 $< $@

mytool1:
	blah mytool1.blah -o $@

mytool2:
	blah mytool2.blah -o $@

.PHONY: part2
part2: part1-done
	${buildtooldir}/mytool1 --process this
	${buildtooldir}/mytool2 --process that

Now I'd certainly agree that this is a weird thing to do, but 'install'
is not only going to be used in GNU packages.  Home-rolled packages
may also use it, and they can basically construct their Makefiles
however they choose (the above will work fine if install actually
creates the requested output file).

> No. IMHO, an 'install' target like the above would violate both any
> existing GNU packaging/coding standard and common sense. 'make install'
> is a volatile target (.PHONY, in make terms). If at all, the rule 
I agree - but as I said, not all uses for install will be in packages
following GNU (or, indeed, any) coding standards.