zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Zefram <zefram@fysh.org>
Cc: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR)
Date: Sun, 24 Oct 1999 21:55:20 +0000	[thread overview]
Message-ID: <991024215520.ZM13069@candle.brasslantern.com> (raw)
In-Reply-To: <E11fUoB-0007l4-00@crucigera.fysh.org>

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


  reply	other threads:[~1999-10-24 21:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-10-19  5:22 Patch: 3.1.6-bart-7: Another rlimit Bart Schaefer
1999-10-19  6:13 ` PATCH: " Bart Schaefer
1999-10-20 20:17   ` Zefram
1999-10-21  1:53     ` Bart Schaefer
1999-10-24  0:45   ` 3.0 DESTDIR Clint Adams
1999-10-24  1:55     ` Bart Schaefer
1999-10-24  5:05       ` Clint Adams
1999-10-24  6:20         ` Bart Schaefer
1999-10-24 14:30           ` Clint Adams
1999-10-24 14:51             ` Bruce Stephens
1999-10-27  2:17               ` Clint Adams
1999-10-24 17:58             ` PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR) Bart Schaefer
1999-10-24 21:04               ` Zefram
1999-10-24 21:55                 ` Bart Schaefer [this message]
1999-10-24 21:57                 ` Bart Schaefer
1999-10-28  1:58               ` Juergen A. Erhard
1999-10-28  3:31                 ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=991024215520.ZM13069@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=zefram@fysh.org \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).