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 X-Sender: broeker AT acp3bf To: djgpp-workers AT delorie DOT com Subject: RE: Fileutils 4.0 port and ginstall In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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.