search for: proj_obj_root

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

Hi LLVM-folks, is there a way to use the llvm-build tool for out-of-tree projects? Makefile.rules supposes llvm-build to be located in PROJ_SRC_ROOT and this does not hold for out-of-tree projects, the same applies to Makefile.llvmbuild that is searched for in PROJ_OBJ_ROOT. I think PROJ_SRC_ROOT should be replaced by LLVM_SRC_ROOT and PROJ_OBJ_ROOT should be replaced by LLVM_OBJ_ROOT, right? Ciao, Fabian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130122/a2f31c1e/attachmen...

...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 build mode $(LLVM_SRC_ROOT) == $(PROJ_SRC_ROOT) ) and have common problem. If generated Makefile.config u...

...r example, SAFECode doesn't have its own build system; it uses LLVM's, and it does so without being a "patch" to the LLVM source tree. You can put the SAFECode source code anywhere you like, use LLVM-style Makefiles in its source code, and build it. All of the PROJ_SRC_ROOT, PROJ_OBJ_ROOT magic in the autoconf build system is what permits that feature to work. Do you intend to keep this functionality when you replace autoconf with cmake, or will all projects that want to use the LLVM build system need to place their source code in the LLVM source tree? To put it another way, d...

...ECode doesn't have its own build system; it uses LLVM's, and it > does so without being a "patch" to the LLVM source tree. You can put > the SAFECode source code anywhere you like, use LLVM-style Makefiles > in its source code, and build it. All of the PROJ_SRC_ROOT, > PROJ_OBJ_ROOT magic in the autoconf build system is what permits > that feature to work. > > Do you intend to keep this functionality when you replace autoconf > with cmake, or will all projects that want to use the LLVM build > system need to place their source code in the LLVM source tree? To &...

Hi, On Linux I observed [root at localhost poolalloc]# find . -name *.a ./Release+Asserts/lib/LLVMDataStructure.a ./Release+Asserts/lib/poolalloc.a ./Release+Asserts/lib/AssistDS.a ./Release+Asserts/lib/libpoolalloc_fl_rt.a ./Release+Asserts/lib/libpoolalloc_rt.a ./Release+Asserts/lib/libpa_pre_rt.a ./Release+Asserts/lib/libcount.a On cygwin I observed kpawar at KPAWAR-LT

Hi Fabian, > is there a way to use the llvm-build tool for out-of-tree projects? > Makefile.rules supposes llvm-build to be located in PROJ_SRC_ROOT and this does > not hold for out-of-tree projects, the same applies to Makefile.llvmbuild that > is searched for in PROJ_OBJ_ROOT. I think PROJ_SRC_ROOT should be replaced by > LLVM_SRC_ROOT and PROJ_OBJ_ROOT should be replaced by LLVM_OBJ_ROOT, right? for an out-of-tree build you can use llvm-config to get include paths and so on. I don't think there is any point bothering with llvm-build for this case. Ciao, Duncan...

I’ve run into a bizarre error in which LLVM_SRC/Makefile.rules is trying to access a file that doesn’t exist, even though I’ve made sure to correctly reference the needed file. In LLVM_SRC/Makefile.rules, lines 183 and 184 reference the variable ConfigStatusScript, which is defined as $(PROJ_OBJ_ROOT)/config.status. Given the way PROJ_OBJ_ROOT is defined, this means ConfigStatusScript is defined as LLVM_OBJ/config.status. However, lines 183 and 184 appear to searching for the file “config.status” in LLVM_SRC/projects/safecode/tools/clang. Here is some text from the command line that illustra...

Dear All, Will the LLVM project system (the extension to the build system that allows sub-projects to reuse the LLVM Makefiles) be maintained long term, or is the slow push to CMake intending to deprecate this functionality? We used this feature a lot for research projects at UIUC, but if the current maintainers of the build system are planning on deprecating it, I'll have my students

On Wed, May 7, 2014 at 8:28 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Anton Korobeynikov" <anton at korobeynikov.info> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: "Alexey Samsonov" <samsonov at google.com>, "LLVM Developers Mailing > List" <llvmdev at

...ran, > > Which version of LLVM/SAFECode are you using? Is it LLVM 3.2? > > I'm guessing that you're using LLVM 3.2 and trying to compile > safecode/tools/LTO (that's the only component that links in AssistDS.a). > You could try changing the following line: > > $(PROJ_OBJ_ROOT)/$(BuildMode)/lib/libAssistDS.a: > $(POOLALLOC_OBJDIR)/$(BuildMode)/lib/AssistDS.a > > ... to: > > $(PROJ_OBJ_ROOT)/$(BuildMode)/lib/libAssistDS.a: > $(POOLALLOC_OBJDIR)/$(BuildMode)/lib/libAssistDS.a > > You'll need to fix the problem for other libraries for which SAFEC...

...LVM_SRC_ROOT vars). At this moment I am test ability use installed LLVM version to build project instead requare have builded LLVM object dir. And i have problem with installed LLVM include dir. Makefile.rules install only $(PROJ_SRC_ROOT)/include (including *.in files) and ignore headers in $(PROJ_OBJ_ROOT)/include As result installed LLVM does't have all headers for building external projects, for example, llvm/ADT/iterator Proposed patch attached. It tested making full LLVM build, install and uninstall. Vladimir -------------- next part -------------- A non-text attachment was scrubbed... N...

...s may be lost. Since the generation of the actual .d files is somewhat unpredictable (i.e. whenever someone changes the file) this can lead to very sporadic build failures or miscompiles. Does anyone have a good solution to this problem? One possible solution which seems to work for me is to force PROJ_OBJ_ROOT to be a hard path using realpath() via 'readlink -f'. This is fairly straightforward to do, but I am not sure of its portability, or if there are any unintended consequences. - Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/...

...hile organizing the project in a configureable way. In my intial solution the clangAddons lib resides in a sub-directory of my main project (the QT app) as it does in my SVN. However I'm not able to build from there since the line PROJ_SRC_DIR := $(shell cd $(LLVM_SRC_ROOT)/$(patsubst $(PROJ_OBJ_ROOT)%,%,$(PROJ_OBJ_DIR)); $(PWD)) fails if LEVEL contains other things then multiple "../" OTOH I don't want to put the lib in llvm/tools as this would not only make the project checkout more difficult but also overcomplicates the sharing of some configuration variables (namely boost...

Reading Makefile.rules i found some unclear places in file: Line 553: LinkMOdule += -Xlinker -internalize-public-api-file=$(EXPORTED_SYMBOL_FILE) Maybe it must be LinkModule += ... ? Line 1283: DistCheckDir := $(LLVM_OBJ_ROOT)/_distcheckdir Maybe it must be: DistCheckDir := $(PROJ_OBJ_ROOT)/_distcheckdir Vladimir

...:= $(PROJ_SRC_ROOT)/utils/llvm-build/llvm-build however in the case of vmkit it should be LLVMBuildTool := $(LLVM_SRC_ROOT)/utils/llvm-build/llvm-build i Also noticed that in the vmkit's generated (by configure) Makefile.config there are defined PROJ_SRC_ROOT and VMKIT_SRC_ROOT as well as PROJ_OBJ_ROOT and VMKIT_OBJ_ROOT. What should be the difference between PROJ_* and VMKIT_* paths? In my case they where equal (so what's the need for 2 different variables?) I hope the first section will help you to create a patch (i edited my Makefile.rules just before configuring vmkit to make it work)...

On Thu, 3 Feb 2005, Vladimir Merzliakov wrote: >> Doing it this way >> allows you to re-use the LLVM build system, as opposed to building your >> own set of Makefiles. > I have pre-LLVM projects in C++ with often used at Unix C++ source file > extention .cc > I modify LLVM build system (original LLVM Makefile.rules already partly > support .cc extention, > for

> Doing it this way > allows you to re-use the LLVM build system, as opposed to building your > own set of Makefiles. I have pre-LLVM projects in C++ with often used at Unix C++ source file extention .cc I modify LLVM build system (original LLVM Makefile.rules already partly support .cc extention, for example, in Sources and FakeSources make vars setup code). Is attached patch

Hi Nicolas, it looks like there are missing things $ more lib/j3/LLVMRuntime/LLVMRuntime.inc // Generated by llvm2cpp - DO NOT MODIFY! Module* makeLLVMModuleContents(Module *mod) { mod->setModuleIdentifier("<stdin>"); // Type Definitions // Function Declarations // Global Variable Declarations // Constant Definitions // Global Variable Definitions // Function

...-**build/llvm-build > however in the case of vmkit it should be > LLVMBuildTool := $(LLVM_SRC_ROOT)/utils/llvm-**build/llvm-build > > i Also noticed that in the vmkit's generated (by configure) > Makefile.config there are defined PROJ_SRC_ROOT and VMKIT_SRC_ROOT as well > as PROJ_OBJ_ROOT and VMKIT_OBJ_ROOT. What should be the difference between > PROJ_* and VMKIT_* paths? In my case they where equal (so what's the need > for 2 different variables?) > > I hope the first section will help you to create a patch > (i edited my Makefile.rules just before configuring v...