similar to: [LLVMdev] Updatings With SRCDIR == OBJDIR

Hi. The choice of 'config.h' for testing does not consider the possiblity of objdir != srcdir builds. The small patch below replaces 'config.h' with 'configure.in' in keeping with the 'config' name choice. Art Haas Index: testsuite/itemize.test =================================================================== RCS file: /cvsroot/rsync/testsuite/itemize.test,v

LLVM makefiles can't detect source changes in case objdir != srcdir, e.g. I've managed to get my pass listed in 'opt -help' only after removing opt subdir from objdir and running make again. Re-configuring LLVM also does not trigger rebuild when running make, e.g. after initial 'configure --enable-targets=x86' I've managed to get C backend only after removing objdir and

On Tuesday 05 January 2010 03:38, Gregory Petrosyan wrote: > LLVM makefiles can't detect source changes in case objdir != srcdir, e.g. I haven't found that. I build with objdir != srcdir all the time. > I've managed to get my pass listed in 'opt -help' only after removing opt > subdir from objdir and running make again. Re-configuring LLVM also does It sounds like

Two suggestions: 1. m4 might be located by your PATH variable. 2. Talk to Morten Ofstad about how he got it to work. Reid. On Wed, 2004-11-03 at 19:34, Jeff Cohen wrote: > I have problems getting the GNU tools to execute properly. I installed > bison, sed, and flex from gnuwin32.sourceforge.net as suggested in the > README. The installers for these packages did not want to put them

Hello, I would like to run a SPEC benchmark from llvm-test, with objdir != srcdir. Right now it doesn't work because the config file External/SPEC/Makefile.spec.config is not created by the configure script in the target objdir. The attached patch adds the above Makefile to the list of Makefile(s) configure has to process. I have tested it on my local tree (needs to regenerate configure).

I have problems getting the GNU tools to execute properly. I installed bison, sed, and flex from gnuwin32.sourceforge.net as suggested in the README. The installers for these packages did not want to put them in the llvm/win32/{tools,share} directory, which is unfortunately where the project files expect them to be. I copied the files manually to these directories, but bison still refuses to

On Tuesday 05 January 2010 12:18, Gregory Petrosyan wrote: > > It sounds like the dependencies for your pass are not correct. Where > > did you put it in the LLVM tree and how did you change the Makefiles? > > One new .cpp file in lib/Transforms/IPO + RegisterPass<> + mention pass in > LinkAllPasses.h; no changes in makefiles. Hmm, that should certainly work. What

On 2010-01-05 22:21, David Greene wrote: > On Tuesday 05 January 2010 13:33, Gregory Petrosyan wrote: > > >>>>> A non-build after reconfigure is not really a problem. If nothing in >>>>> the configuration has changed configure is smart enough not to update >>>>> anything so make doesn't see any changes. >>>>>

On Tue, Jan 05, 2010 at 11:30:41AM -0600, David Greene wrote: > > I've managed to get my pass listed in 'opt -help' only after removing opt > > subdir from objdir and running make again. Re-configuring LLVM also does > > It sounds like the dependencies for your pass are not correct. Where > did you put it in the LLVM tree and how did you change the Makefiles?

On Tuesday 05 January 2010 13:33, Gregory Petrosyan wrote: > > > > A non-build after reconfigure is not really a problem. If nothing in > > > > the configuration has changed configure is smart enough not to update > > > > anything so make doesn't see any changes. > > > > > > Yes, but in my case support for new targets should be built in.

On Tue, Jan 05, 2010 at 01:05:56PM -0600, David Greene wrote: > On Tuesday 05 January 2010 12:18, Gregory Petrosyan wrote: > > > > It sounds like the dependencies for your pass are not correct. Where > > > did you put it in the LLVM tree and how did you change the Makefiles? > > > > One new .cpp file in lib/Transforms/IPO + RegisterPass<> + mention pass

This patchs adds better support for both Flex and Bison, which might be needed to compile libxl. Now configure script sets BISON and FLEX Makefile vars if bison and flex are found, but doesn''t complain if they are not found. Also, added some Makefile soccery to print a nice error message if Bison or Flex are needed but not found. Please run autogen after applying this patch.

On Mon, Sep 17, 2007 at 12:25:40PM -0700, Chris Lattner wrote: > On Mon, 17 Sep 2007, Emil Mikulic wrote: > >> The 2.1 pre-release (version 1) is available for testing: > >> http://llvm.org/prereleases/2.1/version1/ > > > > I suspect the utils/TableGen/FileParser.h.cvs in the tarball may be > > stale. I tried building LLVM without bison installed and got:

Like I said, it is in my path. That's not enough. I'd be happy if Morten chimed in with any suggestions as to how he got it to work. On Thu, 04 Nov 2004 18:45:18 -0800 Reid Spencer <reid at x10sys.com> wrote: > Two suggestions: > > 1. m4 might be located by your PATH variable. > 2. Talk to Morten Ofstad about how he got it to work. > > Reid. > > On

Hello, Everyone. This is just brief description on building llvm-gcc4 with mingw32. It's definitely non error-free and contains many "hacks", which should be eliminated in the future. 1. Prerequisites We're building in the folowing configuration: 1.1 GCC 3.4.5: gcc -v Reading specs from f:/research/mingw/bin/../lib/gcc/mingw32/3.4.5/specs Configured with:

Hey, everybody--- Ignorance CAN be bliss, at least for a while, but, .... Just so you know... A week or two ago, some upgrades to the expression parser (you know, the expressions you put in $[ ... ] in your extensions.conf file) that I submitted, have been merged into the CVS HEAD of the source. Hopefully, for around 99.9% of you, it won't make any difference to you. The Makefile has also

On Mon, 27 Jun 2005, Alexander Friedman wrote: > Hi all, > have flex/bison. Most (but not all) unix boxes have them, but almost > no windows boxes have them. This requires either > > 1) Forcing the user to dowload flex/bison (bad) > 2) Distributing flex/bison with the front-end (not as bad, but a pain) > > 3) or, and this seems like a simple fix, just distribute the output

On 6/29/05, Chris Lattner <sabre at nondot.org> wrote: > On Mon, 27 Jun 2005, Alexander Friedman wrote: > > Hi all, > > have flex/bison. Most (but not all) unix boxes have them, but almost > > no windows boxes have them. This requires either > > > > 1) Forcing the user to dowload flex/bison (bad) > > 2) Distributing flex/bison with the front-end (not as

Hi all, At the moment, LLVM includes the .l, .y sources that are compiled by flex and biston via make. This is fine for most unix developers. For windows developers, it's a bit more of a pain to download flex/bison, but is still a one-time thing. However, anyone releasing an llvm frontend will require their users to have flex/bison. Most (but not all) unix boxes have them, but almost no

> llvm[2]: Flexing FileLexer.l > llvm[2]: Bison of FileParser.y SKIPPED -- bison not found > llvm[2]: Compiling FileLexer.cpp for Release build > /usr/home/emil/llvm-2.0/utils/TableGen/FileLexer.l:34:24: FileParser.h: No such file or directory > > Is this a packaging issue where FileParser.h was omitted > from the tarball, or does LLVM *need* bison in order to build? No,