From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16531 invoked from network); 24 Oct 1999 21:55:38 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 24 Oct 1999 21:55:38 -0000 Received: (qmail 23841 invoked by alias); 24 Oct 1999 21:55:33 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8396 Received: (qmail 23833 invoked from network); 24 Oct 1999 21:55:31 -0000 From: "Bart Schaefer" Message-Id: <991024215520.ZM13069@candle.brasslantern.com> Date: Sun, 24 Oct 1999 21:55:20 +0000 In-Reply-To: Comments: In reply to Zefram "Re: PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR)" (Oct 24, 10:04pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: Zefram Subject: Re: PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) Cc: zsh-workers@sunsite.auc.dk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 24, 10:04pm, Zefram wrote: } Subject: Re: PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) } } Bart Schaefer wrote: } >This means that "make MODDIR=/some/new/path fndir=/some/other/new/path" } >does not recompile zsh, } } I intentionally wrote that code so that that *would* cause a recompile. I understand that. } Btw, my view is that giving different parameters to "make install" } from those one gave to "make" is a bad practice, but if it is to be } supported then the parameters from "make install" must take precedence. Unfortunately, it's my understanding that the GNU-accepted practice for changing the install location of software that is under autoconf/configure control is exactly what my patch permits. Of course we're not actually GNU-ware (thank goodness) so we can ignore that if we choose, but it's been causing me to have to copy things into the install directories by hand for as long as I've been building 3.1.x. Did you read my description of the "stow" utility? If "make install" alters the binary, how does one produce a correctly-configured binary that can be managed by such a utility? } After all, those are the parameters that will take effect if anything } changes and gets rebuilt during the "make install". Yes, that's true. It's up to a package installer to do the steps in the right order: That is, never "make install" without first doing "make". } Let's keep configured pathnames and install paths properly distinct. Exactly. Paths that are hardwired into compiled components should be those specified at configure time, not those specified at "make" time. That's why they call it "configure". Unfortunately, without a much more significant rewrite of the module build system, we can't achieve that. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com