similar to: [LLVMdev] Multiple directories in a single library

Hello, Matthijs > There is some code in llvm-config which fixes the library problem for the > TargetNameAsmPrinter library, but that isn't really the clean way IMHO. Is > this also meant for cleanup, or is there another reason why the AsmPrinter > should be in a seperate library? The main reason of such split was codesize concerns for JIT users: they don't need asmprinting at

Hi Torok, I've used a hard-coded list on the input parameter and still got some output (slightly) scrambled between two different bots... INPUT = $(PROJ_SRC_DIR)/inputs/clam.cab \ $(PROJ_SRC_DIR)/inputs/clamdoc.tar.gz \ $(PROJ_SRC_DIR)/inputs/clam.exe \ $(PROJ_SRC_DIR)/inputs/clam.exe.bz2 \ $(PROJ_SRC_DIR)/inputs/clam-v2.rar \

1) I find typo in Makefile.rules in printvars rule: - $(Echo) "Preconditions: " '$(Preconditions)' + $(Echo) "PreConditions: " '$(PreConditions)' 2) In Makefile.config.in PROJ_SRC_DIR define for LLVM build mode as PROJ_SRC_DIR := $(subst //,/,$(LLVM_SRC_ROOT)/$(patsubst $(PROJ_OBJ_ROOT)%,%,$(PROJ_OBJ_DIR))) and for other project build mode as PROJ_SRC_DIR

Hi Daniel, I know you only did a small change to support big/little endian reference outputs, but maybe you can help me. I'm running the test-suite on AArch64 and it's correctly detecting little-endian, even setting the ENDIAN=little on configure and Makefiles alike, but it still generates "big-endian" from Makefile.programs. Here's the first lines of: sandbox/test-...$

Hello, Tatu > Is that correct? I think it's just something to be aware of. Currently we're aggressively merging globals by default. Do you think it will be better to provide special flag to control this behavior? -- WBR, Anton Korobeynikov

On Oct 17, 2008, at 7:30 AM, Anton Korobeynikov wrote: > Hello, Tatu > >> Is that correct? I think it's just something to be aware of. > Currently we're aggressively merging globals by default. Do you > think it > will be better to provide special flag to control this behavior? Please no flag. If we want to fix this problem, lets do it right. To me this

This patch eases building clang when present in the source tree. Since clang is revlocked to llvm, one usually updates them together, and builds them together. Ok? -------------- next part -------------- A non-text attachment was scrubbed... Name: clang-3.patch Type: application/octet-stream Size: 794 bytes Desc: not available URL:

On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen wrote: > In my humble opinion, using OPTIONAL_DIRS would be better and cleaner. > It may require some changes to ‘Makefile.rules’ to work as > intended, though. If there's interest in such a change, I can prepare > a patch? Are OPTIONAL_DIRS parallel? For some reason, I was assuming not.

2009/1/2 Chris Lattner <clattner at apple.com> > On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote: > Do you have a specific example of a unit test that would need these? I > really think these should stay private. > Let's take lib/Transforms/Utils/CodeExtractor.cpp . The public interface for it is in include/llvm/Transform/Utils/FunctionUtils.h, with only the high-level

Hi Erick, Thanks for your patches! On Mar 4, 2008, at 01:33, Erick Tryzelaar wrote: > This is a small bug fix for the ocaml build system that allows > for dependencies to be generated for ocaml interface files. I've committed the second half of this. > --- > bindings/ocaml/Makefile.ocaml | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-)diff --git bindings/

On 17/10/2008, Chris Lattner <clattner at apple.com> wrote: > Please no flag. If we want to fix this problem, lets do it right. To > me this consists of some flag on GlobalVariable that says that it is > 'mergable' or something like that. Wouldn't it be slightly cleaner to mark the distinct objects in the LLVM intermediate representation? This would make the default

On Jan 19, 2009, at 1:58 PM, Chris Lattner wrote: > On Jan 19, 2009, at 10:02 AM, Mike Stump wrote: > >> There isn't a good reason to create files called .dir in the >> installation directory. This patch fixes that. > > If we don't have this line, every build with do the makedir. And? $ time mkdir -p /bin real 0m0.002s user 0m0.000s sys 0m0.002s an extra mkdir

On Jan 19, 2009, at 12:35 PM, Dan Villiom Podlaski Christiansen wrote: > On 19 Jan 2009, at 21:16, Mike Stump wrote: > >> On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen >> wrote: >>> In my humble opinion, using OPTIONAL_DIRS would be better and >>> cleaner. >>> It may require some changes to ‘Makefile.rules’ to work as >>>

Eliminate undefined references to powf, sqrtf and friends. Index: MultiSource/Benchmarks/Bullet/Makefile =================================================================== --- MultiSource/Benchmarks/Bullet/Makefile (revision 92512) +++ MultiSource/Benchmarks/Bullet/Makefile (working copy) @@ -1,7 +1,7 @@ LEVEL = ../../../ PROG = bullet CPPFLAGS += -I$(PROJ_SRC_DIR)/include -DNO_TIME -LDFLAGS

Hi! I'm trying to build a backend outside the LLVM source tree. My directory structure is as follows: llvm -- the root of the LLVM source tree llvm/lib/Target -- where the standard backends are stored (Sparc, etc). my_dir/my_backend -- where I store the backend I'm writing. I've been fiddeling with the variables documented in the llvm/Makefile.common (LEVEL, LLVM_SRC_ROOT,

Hello, Ekaterina. FYI, my configure has '--host=i686-pc-mingw32' w/o any additional variables. and then the build host (ppc fedora 12) has toolchain 'i686-pc-mingw32-*'. It could build everything successfully, but I have not built it for a few months :p 2010/11/30 Ekaterina Sanina <ekaterina.sanina at gmail.com>: > cross-compile-build-tools: >         $(Verb) if [ !

Hello all, I have replaced the llvm-gcc shipped with the Xcode by the latest version and I was wondering if I have missed something... (everything *seems* to work). Here's what I did: 0. Checkout LLVM (and clang) + llvm-gcc 1. Build LLVM (with clang) and install into /Developer/usr/local : # mkdir llvmobj # cd llvmobj # CC=gcc-4.2 CXX=g++-4.2 ../llvm/configure

On May 14, 2008, at 4:46 AM, Dominic Hamon wrote: > Bill Wendling wrote: >> On Tue, May 13, 2008 at 2:24 AM, Joachim Durchholz >> <jo at durchholz.org> wrote: >> >>> Am Dienstag, den 13.05.2008, 00:42 -0700 schrieb Bill Wendling: >>> >>>> Sorry to step into this in the middle of a thread, but what >>>> exactly is

Hi, Using trunk llvm ; on powerpc (powerpc64/power7); trying to do a "gmake check", the sed bits in test/Makefile appear to be getting tripped up when trying to generate lit.site.cfg. I've started to hack at it, made a little bit of progress, but wonder if I'm just digging myself a hole. Highlights of what I've poked at are below.. Comments or thoughts? Thanks,

Morning, Will! 2012/7/12 Will Schmidt <will_schmidt at vnet.ibm.com>: > llvm]$ gmake check > llvm[0]: Running test suite > gmake[1]: Entering directory `/home/willschm/llvm/test' > Making LLVM 'lit.site.cfg' file... > sed: file lit.tmp line 8: unknown option to `s' > gmake[1]: *** [lit.site.cfg] Error 1 > > The relevant lines in test/Makefile: >