delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/03/06/13:09:18

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019