similar to: [LLVMdev] Makefile dependency problems

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

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

>> 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

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?

On Mon, Dec 3, 2012 at 10:47 AM, Daniel Dunbar <daniel at zuster.org> wrote: > On Sat, Dec 1, 2012 at 1:06 AM, Chandler Carruth <chandlerc at google.com> > wrote: >> >> On Fri, Nov 30, 2012 at 8:04 PM, Chris Lattner <clattner at apple.com> wrote: >>> >>> I'm ok with this in principle, but how about with the nuance that some >>>

On Sat, Dec 1, 2012 at 1:06 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Fri, Nov 30, 2012 at 8:04 PM, Chris Lattner <clattner at apple.com> wrote: > >> I'm ok with this in principle, but how about with the nuance that some >> tests (eg test/codegen) explicitly opt into march=native? >> > > I'd really like the default behavior to be

On Mon, Dec 3, 2012 at 10:56 AM, David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Dec 3, 2012 at 10:47 AM, Daniel Dunbar <daniel at zuster.org> wrote: > > On Sat, Dec 1, 2012 at 1:06 AM, Chandler Carruth <chandlerc at google.com> > > wrote: > >> > >> On Fri, Nov 30, 2012 at 8:04 PM, Chris Lattner <clattner at apple.com> > wrote:

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

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

I'm ok with this in principle, but how about with the nuance that some tests (eg test/codegen) explicitly opt into march=native? -Chris On Nov 30, 2012, at 12:16 PM, Daniel Dunbar <daniel at zuster.org> wrote: > Hi all, > > We consistently see test failures arising because by default many of our tests run in a mode where the tool (clang or llc) pick host-dependent behavior.

On 6/18/15 6:49 PM, Eric Christopher wrote: > Hi John, > > Long term we don't want to keep the burden of two build systems in > tree. CMake is turning out to be the build system we want because of > its multi-platform support, etc and as soon as the CMake system can do > everything we can do with the autoconf/makefile build I plan on > turning down the support for that

On Fri, Nov 30, 2012 at 8:04 PM, Chris Lattner <clattner at apple.com> wrote: > I'm ok with this in principle, but how about with the nuance that some > tests (eg test/codegen) explicitly opt into march=native? > I'd really like the default behavior to be something that forces the test to either be independent of the targeted triple, or explicitly set a target. I like the

On Mon, Aug 24, 2009 at 5:40 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: > It seems that support for dumping text representation of LLVM objects to > standard channels and C++ output streams was removed. My guess is that > now we must use errs() instead of std::cerr, llvm::raw_fd_ostream > instead of std::ofstream, etc. Correct. std::ostream has been purged from LLVM; the only

On Fri, Feb 12, 2010 at 5:48 PM, Daniel Dunbar <daniel at zuster.org> wrote: > I am definitely in favor of this if it is ok with Tanya. > > I hope to spend some time in the next few weeks on tracking down > miscompiles, and it would be great to get Clang to the > "early-but-usable-beta" stage so it makes sense to roll binaries for > 2.7. > > Tanya, I can

> On Feb 29, 2016, at 5:59 AM, Sven Templer <sven.templer at gmail.com> wrote: > > Hello, > > sorry for not being clear enough. > > My problem is represented with the following code, running on OSX: > > mkdir ~/test > ln -s ~/test ~/testlink > touch ~/test/foo > Rscript -e 'Sys.readlink(c("~/test/foo", "~/testlink/foo"));

It seems that support for dumping text representation of LLVM objects to standard channels and C++ output streams was removed. My guess is that now we must use errs() instead of std::cerr, llvm::raw_fd_ostream instead of std::ofstream, etc. The changes are not trivial, as for instance llvm::raw_fd_ostream without flags fails if the file exists, but std::ofstream does not. The changes include

----- Original Message ----- > From: "Eric Christopher" <echristo at gmail.com> > To: "John Criswell" <jtcriswel at gmail.com>, LLVMdev at cs.uiuc.edu, "Chris Bieneman" <beanz at apple.com> > Sent: Thursday, June 18, 2015 7:14:06 PM > Subject: Re: [LLVMdev] Long-Term Support for LLVM Projects Extension to Build System? > > > On

Commit-ID: 32b36eb98fafad924f3f69904d74d2f2168a4753 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=32b36eb98fafad924f3f69904d74d2f2168a4753 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Wed, 6 Jan 2016 01:08:47 +0000 Committer: H. Peter Anvin <hpa at linux.intel.com> CommitDate: Tue, 5 Jan 2016 17:48:43 -0800 [klibc] Implement realpath() This

I am definitely in favor of this if it is ok with Tanya. I hope to spend some time in the next few weeks on tracking down miscompiles, and it would be great to get Clang to the "early-but-usable-beta" stage so it makes sense to roll binaries for 2.7. Tanya, I can also do the x86-32-pc-linux release testing if no one else steps up. - Daniel On Fri, Feb 12, 2010 at 3:02 PM, Douglas

I have an environment consisting of: * Primary Workstation running Win2KPro * Secondary Workstation runing WinNTSP6a * Local Win2K Advanced Server * Local Solaris 8 system with Samba 2.0.7 * Remote HP-UX system at Site A with Samba 1.9.18p10 connected via VPN * Remote Unixware system at Site B with Vison(?) file sharing connected via VPN * Three remote Win2K server boxes at Site C connected via