similar to: [LLVMdev] Some bugs (?) in LLVM Makefile.rules file

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?

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

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

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

>> Is attached patch acceptable? > > Looks great, applied, thanks! > http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050131/023931.html Thanks! >> Also I have in Makefile.rules (but not include in patch) some >> modification for simplify used common Makefile.rules in LLVM projects and >> non-LLVM project (guarding some LLVM specific parts by ifdef

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

Vladimir, I took a *very quick* look at your patch. I won't be able to look at it in more detail until this weekend, but perhaps you can address a couple of concerns: 1. I don't understand the need for LLVMToolDirSlash. This seems like a gratuitous change to me. 2. I don't think the change to CPP.Flags is right. It won't find the LLVM header files 3. Removing the

>> Patch attached. >> >> This patch with header installation patch ( >> http://mail.cs.uiuc.edu/pipermail/llvmdev/2005-February/003300.html ) >> let external project (I am test it at my YAFL frontend for LLVM) build >> using installed LLVM version instead using LLVM obj/src dirs. > > I think the patch looks basically sane. The one wierd thing I notice

>> Also I have in Makefile.rules (but not include in patch) some >> modification for simplify used common Makefile.rules in LLVM projects and >> non-LLVM project (guarding some LLVM specific parts by ifdef >> LLVM_OBJ_ROOT/LLVM_SRC_ROOT vars). > > I'm not sure about this, perhaps Reid would like to comment? > Patch attached. This patch with header

Personally, I don't think LLVM projects should need much in the way of autoconf stuff. They certainly don't need to replicate things like install-sh and mkinstalldirs. I'd vote for taking these out of the projects rather than making the makefiles deal with them. I think in most cases these are just historical artifacts that have been with the projects since long before the new

Hi! In current LLVM CVS: llvm/projects/Stacker/Makefile.common.in llvm/projects/sample/Makefile.common.in llvm-java/llvm-java/Makefile.common.in have line: include $(LLVM_OBJ_ROOT)/Makefile.common that have line: include $(LLVM_OBJ_ROOT)/Makefile.config (also $(LLVM_OBJ_ROOT)/Makefile.config used in llvm-test/Makefile.config.in) and llvm/Makefile.config.in have lines: INSTALL_SH :=

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

On Mon, 7 Feb 2005, Vladimir Merzliakov wrote: >>> Also I have in Makefile.rules (but not include in patch) some modification >>> for simplify used common Makefile.rules in LLVM projects and non-LLVM >>> project (guarding some LLVM specific parts by ifdef >>> LLVM_OBJ_ROOT/LLVM_SRC_ROOT vars). >> >> I'm not sure about this, perhaps Reid

Good midnight, Kevin. cygming/shared might have been broken since r112976, IIRC. (ToT, too) A trivial patch; --- a/Makefile.rules +++ b/Makefile.rules @@ -942,6 +942,11 @@ ifdef EXPORTED_SYMBOL_FILE # First, set up the native export file, which may differ from the source # export file. +# The option --version-script is not effective on GNU ld win32. +ifneq (,$(filter $(HOST_OS),Cygwin

On Sat, 2005-06-18 at 10:32 +0200, Henrik Bach wrote: > Hi LLVMers, > > The root of my SRC_DIR is: /home/hb/projects/src/llvm-1/llvm/ > and the root of my OBJ_DIR is: /home/hb/projects/build/FC1/llvm-1-1. > > However, the configure script seems to have stripped some of the / from the > paths: > Makefile.common:63: /home/hb/projects/buildFC1llvm-1-1/Makefile.config: No

Just for information. After root update OS from FreeBSD 5.1 to FreeBSD 5.3-RC1 at make.cc.rsu.ru I don't rebuild LLVM C Frontend. Last LLVM build fail (2004-10-30) is result this situation. I update LLVM C Frontend and rerun manually nighttest script. All ok now :) Also, I think, "X86: FreeBSD 5.1 (may not be run every day)" line at

The new patch works fine, but considering the discussion on the CMake bug tracker, I'm would say that TO_NATIVE_PATH shouldn't be used at all. ________________________________________ From: Dan Liew [dan at su-root.co.uk] Sent: Wednesday, July 23, 2014 10:38 AM To: Mueller-Roemer, Johannes Sebastian Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [patch] EXPORTED_SYMBOL_FILE using mingw

> Vladimir, > > I took a *very quick* look at your patch. I won't be able to look at it in > more detail until this weekend, but perhaps you can address a couple of > concerns: > > 1. I don't understand the need for LLVMToolDirSlash. This seems like a > gratuitous change to me. If LLVM_OBJ_ROOT (with LLVM_SRC_ROOT) and LLVM_ROOT both not set without