similar to: [LLVMdev] llvm build not respecting DESTDIR?

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 :=

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

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, I think it is the first time it is run that the errors occcur !? Not sure but that would seem logical. Aaron

Hi Takumi, > Any feedbacks are welcome. > Have fun! This seems to be pretty useful addition to LLVM on windows! And it seems the only painless way to make plugins working, yay! For me the patch looks pretty good. One minor thing: could you please rename SharedDir => SharedLibDir Thanks! -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg

Good summer, all! This patch enables ENABLE_SHARED=1 to build DLL based LLVM toolchain. I have checked this on Cygwin-1.5, Cygwin-1.7, mingw(msysgit) and mingw-cross-fedora12. I can separate this patch into some parts; cleanups, adding definitions and adding rules. Any feedbacks are welcome. Have fun! ...Takumi * Pros - reduction of linking time of toolchain. - capability of -load

right, but that will lead to directory creation problems on some systems with a fresh install. Reid. On Thu, 2005-02-17 at 15:06, Vladimir Merzliakov wrote: > > Vladimir, > > > > Thanks for the note. Unfortunately, the install approach that we're > > using in the makefiles is a bit broken, based on Linux install program. > > We'll get this cleaned up soon so

> Vladimir, > > Thanks for the note. Unfortunately, the install approach that we're > using in the makefiles is a bit broken, based on Linux install program. > We'll get this cleaned up soon so that it works on multiple unixes. > > Reid. Ok Temporary fixed by partly reverting $(Install) changes in local copy Makefile.rules (removing -D option from $(Install) call

Anton, Thanks for your comment. 2nd patch attached. - s/SharedDir/SharedLibDir/g - move prefix=cyg sunk into if(cygwin or mingw) arigato gozaimasu...Takumi * Additional issues - You may build LLVMHello.dll but I don't modify lib/Transforms/Makefile. Because making LLVMHello.dll requires the library LLVM.dll, but it oughta be on the way to making libs at building

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

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

Reid Spencer wrote: > Yes. Could you please file a bug report for this so we don't forget > about it. I would really appreciate it. > Will do. >> So does that mean that if we're doing a pure llvm, or llvm + llvm-gcc4, >> we can just do "make" and not "make tools-only"? >> > > Yes. The makefile detects llvm-gcc4 and skips the

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, 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

Hello, we had a quick exchange some time ago about putting DESTDIR support in R-Project. DESTDIR is not meant for run-time relocation, but for staged installation. An already configured package can be installed to a temporary destination, with all information, hard-coded paths, or even run-time relocation code referring to the final destination. In attachment you'll find a p1 (and p2, for

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

Reid Spencer wrote: >> If not, does it make >> sense to package the two in the two packages? >> Macports is a source-based >> packaging system, so it would seem odd to have to temporarily install >> llvm-gcc to build llvm, but then install llvm-gcc in a separate package. >> > > That issue goes away with llvm-gcc4. You would simply build llvm and

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

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

LLVMers, On the way to resolving bug 122, I am committing my SymbolTable rewrite. If you are working on anything that uses the SymbolTable, I suggest you read the documentation in include/llvm/SymbolTable.h. The changes I've committed reduce the use of Type::TypeTy. This static member will go away in the future, so please do not propagate new code that uses it. There is no reason to use it