X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Tue, 6 Mar 2001 19:08:57 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	djgpp-workers AT delorie DOT com
Subject:	RE: Fileutils 4.0 port and ginstall
In-Reply-To:	<CAEGKOHJKAAFPKOCLHDIKEEPCBAA.tim.van.holder@pandora.be>
Message-ID:	<Pine.LNX.4.10.10103061903500.1749-100000@acp3bf>
MIME-Version:	1.0
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

On Tue, 6 Mar 2001, Tim Van Holder wrote:

> I suppose a Makefile could have
> 
> install: ${datadir}/mydatafile ${bindir}/myprogram
[...]
> In this case, make install would always copy the program.  But as long as
> such a construct isn't used as part of the build process, that's probably
> 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?

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 
would have to look like this:

install: installdirs datafile programfile
	$(INSTALL_DATA) datafile $(datadir)
	$(INSTALL_PROGRAM) programfile $(bindir)

installdirs:
	-mkdir -p $(datadir)
	-mkdir -p $(bindir)

-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -