similar to: [LLVMdev] make fails to detect changes in case srcdir != objdir

On Tue, Jan 05, 2010 at 11:30:41AM -0600, David Greene wrote: > > I've managed to get my pass listed in 'opt -help' only after removing opt > > subdir from objdir and running make again. Re-configuring LLVM also does > > It sounds like the dependencies for your pass are not correct. Where > did you put it in the LLVM tree and how did you change the Makefiles?

On Tuesday 05 January 2010 12:18, Gregory Petrosyan wrote: > > It sounds like the dependencies for your pass are not correct. Where > > did you put it in the LLVM tree and how did you change the Makefiles? > > One new .cpp file in lib/Transforms/IPO + RegisterPass<> + mention pass in > LinkAllPasses.h; no changes in makefiles. Hmm, that should certainly work. What

On Tuesday 05 January 2010 03:38, Gregory Petrosyan wrote: > LLVM makefiles can't detect source changes in case objdir != srcdir, e.g. I haven't found that. I build with objdir != srcdir all the time. > I've managed to get my pass listed in 'opt -help' only after removing opt > subdir from objdir and running make again. Re-configuring LLVM also does It sounds like

On Tue, Jan 05, 2010 at 01:05:56PM -0600, David Greene wrote: > On Tuesday 05 January 2010 12:18, Gregory Petrosyan wrote: > > > > It sounds like the dependencies for your pass are not correct. Where > > > did you put it in the LLVM tree and how did you change the Makefiles? > > > > One new .cpp file in lib/Transforms/IPO + RegisterPass<> + mention pass

On Tuesday 05 January 2010 13:33, Gregory Petrosyan wrote: > > > > A non-build after reconfigure is not really a problem. If nothing in > > > > the configuration has changed configure is smart enough not to update > > > > anything so make doesn't see any changes. > > > > > > Yes, but in my case support for new targets should be built in.

On 2010-01-05 22:21, David Greene wrote: > On Tuesday 05 January 2010 13:33, Gregory Petrosyan wrote: > > >>>>> A non-build after reconfigure is not really a problem. If nothing in >>>>> the configuration has changed configure is smart enough not to update >>>>> anything so make doesn't see any changes. >>>>>

Hello, I would like to run a SPEC benchmark from llvm-test, with objdir != srcdir. Right now it doesn't work because the config file External/SPEC/Makefile.spec.config is not created by the configure script in the target objdir. The attached patch adds the above Makefile to the list of Makefile(s) configure has to process. I have tested it on my local tree (needs to regenerate configure).

Hi. The choice of 'config.h' for testing does not consider the possiblity of objdir != srcdir builds. The small patch below replaces 'config.h' with 'configure.in' in keeping with the 'config' name choice. Art Haas Index: testsuite/itemize.test =================================================================== RCS file: /cvsroot/rsync/testsuite/itemize.test,v

On Mon, Sep 14, 2015 at 05:50:58AM +0200, celelibi--- via Syslinux wrote: > index a705440..5ef6702 100644 > --- a/mk/efi.mk > +++ b/mk/efi.mk > @@ -10,6 +10,7 @@ core = $(topdir)/core > GCCOPT := $(call gcc_ok,-fno-stack-protector,) > EFIINC = $(objdir)/include/efi > LIBDIR = $(objdir)/lib > +EFIDIR = $(topdir)/gnu-efi/gnu-efi-3.0 Would it make sense to add AROPT =

On Dec 30, 2008, at 2:54 PM, Talin wrote: > OK changes made and new patch attached. Nice +++ utils/unittest/Makefile (revision 0) ... +# This has to come after Makefile.common, since it doesn't allow us to +# override the VPATH value unless we set PROJECT_NAME, which we don't want +# to do. +VPATH = $(LLVM_SRC_ROOT)/utils/unittest/googletest/src/ Why play with VPATH here? What

Hello, The attached patch adds the jcheck target equivalent to make check, but that can run with a -j flag ($ make jcheck -jX). It does not interfere with the regular check, but rather builds on top of the check-one target: it first generates a list of tests to run using RunLLVMTests, and then run those tests according to the supplied -j flag, invoking the check-one target for each one of them.

On 4/19/06, Patrick Meredith <pmeredit at uiuc.edu> wrote: > I haven't seen anyone claim x86 linux objdir == srcdir, so I'll test it out. > Missed the 18th,but I'll try to have it done asap. > > > On Apr 18, 2006, at 2:51 PM, Robert L. Bocchino Jr. wrote: > I'll test on Darwin/PPC, precompiled llvmgcc, objdir == srcdir. > > Rob > Sorry for being

On Apr 5, 2009, at 7:13 AM, Duncan Sands wrote: > On Saturday 04 April 2009 19:12:55 Mike Stump wrote: >> On Apr 4, 2009, at 6:17 AM, Duncan Sands wrote: >>> you need to use a separate objects directory and not build directly >>> in the llvm-gcc tree. For some reason the Apple people placed a >>> file >>> GNUmakefile in the tree which

I haven't seen anyone claim x86 linux objdir == srcdir, so I'll test it out. Missed the 18th,but I'll try to have it done asap. On Apr 18, 2006, at 2:51 PM, Robert L. Bocchino Jr. wrote: > I'll test on Darwin/PPC, precompiled llvmgcc, objdir == srcdir. > > Rob > > On Apr 16, 2006, at 1:42 PM, Chris Lattner wrote: > >> On Sun, 16 Apr 2006, Tanya Lattner

On Tue, Apr 7, 2009 at 12:38 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Bill, > >> We use GNUmakefile to trigger using the build_gcc script. > > thanks for the explanation, but I still don't understand why > it is done this way.  Why not just get Apple people to run some > script, rather than trying to have "make" automagically do an > Apple

I'll test on Darwin/PPC, precompiled llvmgcc, objdir == srcdir. Rob On Apr 16, 2006, at 1:42 PM, Chris Lattner wrote: > On Sun, 16 Apr 2006, Tanya Lattner wrote: >> For testing, we would like a mix of people to do x86 and ppc. >> Please send email to the list if you plan to test, what >> architecture, and if you will use the llvm-gcc binary or compile >> it

Hi Bill, > We use GNUmakefile to trigger using the build_gcc script. thanks for the explanation, but I still don't understand why it is done this way. Why not just get Apple people to run some script, rather than trying to have "make" automagically do an Apple build? > It's not > ideal, but it's all we have at the moment. For LLVM, we placed those > files

Updates the gnu-efi submodule to the latest version (f64cef26) Changes to the gnu-efi makefiles require changes to the syslinux build scripts. Mainly, the install targets dropped the $(SRCDIR) prefix, e.g. - $(INSTALL) -m 644 $(SRCDIR)/elf_$(ARCH)_efi.lds $(INSTALLROOT)/$(LIBDIR) + $(INSTALL) -m 644 elf_$(ARCH)_efi.lds $(INSTALLROOT)/$(LIBDIR) Since syslinux cd's to $(objdir)

Folks, If your build tree is the same as your source tree and you do a "cvs update", you'll likely run into some issues as a result of PR614 changes I made over the weekend. In this situation, cvs will complain that it can't update certain files because there's a local copy in the way. This is a result of the fact that generated flex/bison files are now checked into cvs.

If you're on the new Makefile system, you will want to update your Makefile.rules. The patch below provides some important fixes for parallel builds and dependencies. It also adds some new features like the -local targets. For example, you can now build "all-local" to build the local directory without recursing into subdirectories. See the comments below for details of the change.