similar to: R-Project build system: DESTDIR support

Hello, I am writing you about the GNU R-Project, as part of by effort to help GNU projects provide a better, more consistent build system. Currently, your project does not support the DESTDIR variable in generated Makefiles (marked as optional in the GNU coding policies, make and automake manual). In my opinion, DESTDIR support can be very helpful for the user, the distribution-specific

Hi Erick, On Fri, 2006-12-08 at 19:27 -0800, Erick Tryzelaar wrote: > Reid Spencer wrote: > > Yes, but its a bit verbose. The variables that control this are all > > defined in the Makefile.config file. The variables are: > > > > PROJ_prefix := /proj/llvm/install-1 > > PROJ_bindir := /proj/llvm/install-1/bin > > PROJ_libdir :=

Reid Spencer wrote: > Yes, but its a bit verbose. The variables that control this are all > defined in the Makefile.config file. The variables are: > > PROJ_prefix := /proj/llvm/install-1 > PROJ_bindir := /proj/llvm/install-1/bin > PROJ_libdir := /proj/llvm/install-1/lib > PROJ_datadir := /proj/llvm/install-1/share > PROJ_docsdir :=

https://bugzilla.mindrot.org/show_bug.cgi?id=1505 Summary: default Solaris make does not pass DESTDIR Product: Portable OpenSSH Version: 5.1p1 Platform: All OS/Version: Solaris Status: NEW Severity: minor Priority: P5 Component: Build system AssignedTo: unassigned-bugs at mindrot.org

The two one-liner patches below are made against the current tinc CVS tree. The debian/rules patch replaces the prefix=blah on the "make install" line with DESTDIR=blah. The prefix is correctly set for /usr, but is overridden with the current make install. DESTDIR is the clean way to relocate the installation into the debian/tmp build dir. The second patch strips the newline off

The default make targets in the top level makefile set DESTDIR which gets applied when the stubdom makefile tries to do a make install within gmp to install libgmp.a to the cross root. Ian, do you want to apply this to your tree and commit the whole thing or would you prefer I roll out a fresh new patch set with all updates applied? Signed-off-by: Matthew Fioravante

Hi, I've been patching OpenSSH [portable] so that I can override DESTDIR when cross-compiling. Is there any reason not to allow this in the general case? Thanks! -- Matthew L. Creech

Hi! I'm trying to cross-compile 4.8-STABLE world to install it over NFS later. I have ./make.conf: # start of file CPUTYPE=i486 KERNCONF?=CONS MODULES_WITH_WORLD=true DESTDIR=/mnt/cons # end of file I run: dir=`pwd` make __MAKE_CONF=$dir/make.conf buildworld 2>&1 | tee $dir/bw.log It fails: ===> gnu/usr.bin/groff/contrib ===> gnu/usr.bin/groff/contrib/mm sh

Hi, The Makefiles in the tinc/po dir don't respect the DESTDIR environment variable. This prohibits rpm packages from installing the l10n files. The debian package tools don't have that problem as they chroot. When building rpms, the l10n files get installed into the real root - not very nice. I don't know how to edit the Makefile.in.in files, I can find out but it'd be nicer if

Hi Erick, On Thu, 2006-12-07 at 23:31 -0800, Erick Tryzelaar wrote: > Hello, > > I'm updating the macports build of llvm, and I'm running into an issue > trying to stage llvm into a temporary directory. It builds fine, but > when I try to install it into a temporary location, it insists on > installing into the final location. Okay. > The only reference I saw

Hello, I'm updating the macports build of llvm, and I'm running into an issue trying to stage llvm into a temporary directory. It builds fine, but when I try to install it into a temporary location, it insists on installing into the final location. The only reference I saw to the standard gnu DESTDIR was in the llvm.spec file, but none of the generated Makefiles have that value. Is

On 18/09/2015 18:29, Claudio Fontana wrote: > > this is a first RFC for virtio-peer 0.1, which is still very much a work in progress: > > https://github.com/hw-claudio/virtio-peer/wiki > > It is also available as PDF there, but the text is reproduced here for commenting: > > Peer shared memory communication device (virtio-peer) Apart from the windows idea, how does

On 18/09/2015 18:29, Claudio Fontana wrote: > > this is a first RFC for virtio-peer 0.1, which is still very much a work in progress: > > https://github.com/hw-claudio/virtio-peer/wiki > > It is also available as PDF there, but the text is reproduced here for commenting: > > Peer shared memory communication device (virtio-peer) Apart from the windows idea, how does

On Mon, Sep 07, 2015 at 02:38:34PM +0200, Claudio Fontana wrote: > Coming late to the party, > > On 31.08.2015 16:11, Michael S. Tsirkin wrote: > > Hello! > > During the KVM forum, we discussed supporting virtio on top > > of ivshmem. I have considered it, and came up with an alternative > > that has several advantages over that - please see below. > >

On Fri, Sep 11, 2015 at 05:39:07PM +0200, Claudio Fontana wrote: > On 09.09.2015 09:06, Michael S. Tsirkin wrote: > > On Mon, Sep 07, 2015 at 02:38:34PM +0200, Claudio Fontana wrote: > >> Coming late to the party, > >> > >> On 31.08.2015 16:11, Michael S. Tsirkin wrote: > >>> Hello! > >>> During the KVM forum, we discussed supporting

Claudio Fontana wrote on 2015-09-07: > Coming late to the party, > > On 31.08.2015 16:11, Michael S. Tsirkin wrote: >> Hello! >> During the KVM forum, we discussed supporting virtio on top >> of ivshmem. I have considered it, and came up with an alternative >> that has several advantages over that - please see below. >> Comments welcome. > > as Jan

On 2015-09-18 23:11, Paolo Bonzini wrote: > On 18/09/2015 18:29, Claudio Fontana wrote: >> >> this is a first RFC for virtio-peer 0.1, which is still very much a work in progress: >> >> https://github.com/hw-claudio/virtio-peer/wiki >> >> It is also available as PDF there, but the text is reproduced here for commenting: >> >> Peer shared memory

On 2015-09-21 14:13, Michael S. Tsirkin wrote: > On Fri, Sep 18, 2015 at 06:29:27PM +0200, Claudio Fontana wrote: >> Hello, >> >> this is a first RFC for virtio-peer 0.1, which is still very much a work in progress: >> >> https://github.com/hw-claudio/virtio-peer/wiki >> >> It is also available as PDF there, but the text is reproduced here for

On Fri, Sep 18, 2015 at 06:29:27PM +0200, Claudio Fontana wrote: > Hello, > > this is a first RFC for virtio-peer 0.1, which is still very much a work in progress: > > https://github.com/hw-claudio/virtio-peer/wiki > > It is also available as PDF there, but the text is reproduced here for commenting: > > Peer shared memory communication device (virtio-peer) >

On Fri, Sep 18, 2015 at 06:29:27PM +0200, Claudio Fontana wrote: > Hello, > > this is a first RFC for virtio-peer 0.1, which is still very much a work in progress: > > https://github.com/hw-claudio/virtio-peer/wiki > > It is also available as PDF there, but the text is reproduced here for commenting: > > Peer shared memory communication device (virtio-peer) >