search for: proj_src_dir

On 2 April 2013 21:20, Török Edwin <edwin+ml-debian at etorok.net> wrote: > You can pass all the filenames from the inputs/ directory directly on the > command-line, instead of specifying -r inputs/. > That way the order of scanning will be exactly the one specified on the > command-line. > Hum, I think I can fix that with Make... --renato -------------- next part

On 04/02/2013 11:06 PM, Daniel Dunbar wrote: > On Tue, Apr 2, 2013 at 11:46 AM, Renato Golin <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> wrote: > > On 2 April 2013 19:20, Daniel Dunbar <daniel at zuster.org <mailto:daniel at zuster.org>> wrote: > > What is it that makes the output of the program asynchronous? The output is

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 \ $(PROJ_SRC_DIR)/inputs/clam-v3.rar \ $(PROJ_SRC_DIR)/inputs/clam.zip \ $(PR...

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 := $(subst //,/,$(PROJ_SRC_ROOT)/$(patsubst $(PROJ_OBJ_ROOT)%,%,$(PROJ_OBJ_DIR))) This two definition is equal (in LLVM...

Reid, I think it is the first time it is run that the errors occcur !? Not sure but that would seem logical. Aaron

...g.log:ac_cv_c_bigendian=no config.log:ENDIAN='little' config.status:s, at ENDIAN@,|#_!!_#|little,g configure.log:checking whether byte ordering is bigendian... no grep: External: Is a directory Makefile.config:ENDIAN := little === So far, so good. Makefile.programs: -if [ -f "$(PROJ_SRC_DIR)/$*.reference_output.$(ENDIAN)-endian.$(REFERENCE_OUTPUT_KEY)" ]; then \ Makefile.programs: cp $(PROJ_SRC_DIR)/$*.reference_output.$(ENDIAN)-endian.$(REFERENCE_OUTPUT_KEY) $@; \ Makefile.programs: elif [ -f "$(PROJ_SRC_DIR)/$*.reference_output.$(ENDIAN)-endian" ]; then \...

...h which facilitates this. It allows you to define the EXTRA_SOURCES variable to explicitely add extra source files (one could also explicitly define SOURCES, but this way you don't loose the default all-sources-in-the-current-dir feature). For example, I would add: EXTRA_SOURCES = $(wildcard $(PROJ_SRC_DIR)/SubDir/*.cpp) to get all the cpp files in SubDir compiled as well. It would be more elegant to specify EXTRA_DIRS instead (or perhaps a better name) as a list of directories, and let Makefile.rules handle the wildcarding here. However, I've not found a way to write .for DIR in $(EXTRA_DIRS)...

...ng 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: @$(ECHOPATH) s=@OCAMLOPT@=$(OCAMLOPT) -cc \"$(CXX_FOR_OCAMLOPT)\" -I $(LibDir)/ocaml=g >> lit.tmp @sed -f lit.tmp $(PROJ_SRC_DIR)/lit.site.cfg.in > $@ And the line in the lit.tmp file: s=@OCAMLOPT@=/bin/ocamlopt -cc "g++ -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64" -I /home/willschm/llvm/Debug+Asserts/lib/ocam...

...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 = -lstdc++ +LDFLAGS = -lstdc++ -lm include $(LEVEL)/Makefile.config

...s 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, PROJ_SRC_DIR, etc) but without success. Is what I'm trying to do possible with the LLVM buildsystem? If so, how? Thank you! / Torgny -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101117/6de0f0ad/attachment.html&...

...R) BuildTools; \ >           cd BuildTools ; \ >           unset CFLAGS ; \ >           unset CXXFLAGS ; \ > +         AR=$(BUILD_AR) ;\ > +         AS=$(BUILD_AS) ;\ > +         LD=$(BUILD_LD) ;\ > +         CC=$(BUILD_CC) ;\ > +         CXX=$(BUILD_CXX) ;\ >           $(PROJ_SRC_DIR)/configure --build=$(BUILD_TRIPLE) \ >                 --host=$(BUILD_TRIPLE) --target=$(BUILD_TRIPLE); \ >           cd .. ; \ +1. It would be useful when buildhost's cc is not 'gcc'. eg. BUILD_CXX='ccache g++' ...Takumi

...akefile.ocaml > index 6fc9a9a..d505ad8 100644 > --- bindings/ocaml/Makefile.ocaml > +++ bindings/ocaml/Makefile.ocaml > @@ -58,7 +58,7 @@ Archive.CMXA := $(strip $(OCAMLOPT) -a $ > (OCAMLAFLAGS) $(OCAMLDEBUGFLAG) -o) > > # Source files > OcamlSources1 := $(sort $(wildcard $(PROJ_SRC_DIR)/*.ml)) > -OcamlHeaders1 := $(OcamlSources1:.ml=.mli) > +OcamlHeaders1 := $(sort $(wildcard $(PROJ_SRC_DIR)/*.mli)) Not sure how an .mli without a corresponding .ml would be useful, so I left this bit. Thanks! Gordon

...uildTools/Makefile ]; then \ $(MKDIR) BuildTools; \ cd BuildTools ; \ unset CFLAGS ; \ unset CXXFLAGS ; \ + AR=$(BUILD_AR) ;\ + AS=$(BUILD_AS) ;\ + LD=$(BUILD_LD) ;\ + CC=$(BUILD_CC) ;\ + CXX=$(BUILD_CXX) ;\ $(PROJ_SRC_DIR)/configure --build=$(BUILD_TRIPLE) \ --host=$(BUILD_TRIPLE) --target=$(BUILD_TRIPLE); \ cd .. ; \ This workaround worked. But I'm sure there is some other, more elegant way of doing it (without actually changing llvm/Makefile). I'm sure other people have done Ca...

...; (and > the llvm makefiles), I am unable to add extra include paths to the > build. It seems that they get into the makefiles ok, but not through > to > the compiler itself. > What variable are you setting? Here's what the clang project uses in its Makefiles CPPFLAGS += -I$(PROJ_SRC_DIR)/../../include I *think* that specifying CPPFLAGS on the command line (like this $ make CPPFLAGS=-I/my/own/include/dir will replace the CPPFLAGS' initial value in the Makefiles. -bw

Still no complete go, doing the tests on i386 failed with some weird sed error: [...] Making Unit/lit.site.cfg for Clang extra tools... sed: lit.tmp: No such file or directory Makefile:61: recipe for target 'Unit/lit.site.cfg' failed gmake[2]: *** [Unit/lit.site.cfg] Error 1 Strangely enough, this does not happen on amd64. Maybe it is some sort of race condition? Did anybody see this

...sed: file lit.tmp line 8: unknown option to `s' > gmake[1]: *** [lit.site.cfg] Error 1 > > The relevant lines in test/Makefile: > @$(ECHOPATH) s=@OCAMLOPT@=$(OCAMLOPT) -cc \"$(CXX_FOR_OCAMLOPT)\" -I $(LibDir)/ocaml=g >> lit.tmp > @sed -f lit.tmp $(PROJ_SRC_DIR)/lit.site.cfg.in > $@ > > And the line in the lit.tmp file: > s=@OCAMLOPT@=/bin/ocamlopt -cc "g++ -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64" -I /home/willschm/llvm/Debug+As...

...HTML > docs yet because I am still thinking about what to write. > - I probably made some mistakes in setting up the makefile rules - that > is what took the most time - so it will merit heightened scrutiny. > > +++ unittests/Makefile.unittest (revision 0) [...] +VPATH=$(PROJ_SRC_DIR) $(PROJ_SRC_ROOT)/unittests That doesn't look like a valid path to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081230/1702d213/attachment.html>

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 >>> LLVM's autoconf doing that "autoconf shouldn't do if properly set up"?

...ify that your sources are compiled with -g? I think so, this is the makefile (based on the one in the Hello pass): > LEVEL = ../../.. > LIBRARYNAME = CGF > LOADABLE_MODULE = 1 > USEDLIBS = > > ifneq ($(REQUIRES_RTTI), 1) > ifneq ($(REQUIRES_EH), 1) > EXPORTED_SYMBOL_FILE = $(PROJ_SRC_DIR)/CGF.exports > endif > endif > > include $(LEVEL)/Makefile.common and this is the invocation: > cafxx at ubuntu:~/Projects/llvm2/lib/Transforms/cgf$ make > llvm[0]: Compiling CGFPass.cpp for Debug+Asserts build (PIC) > llvm[0]: Linking Debug+Asserts Loadable Module CGF.so --...

This is a small bug fix for the ocaml build system that allows for dependencies to be generated for ocaml interface files. --- bindings/ocaml/Makefile.ocaml | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 7c62c2cd93a6402e5f6ebd600e9e3ac7851b4d29.diff Type: text/x-patch Size: 994 bytes Desc: not