search for: gnumakefil

On Apr 4, 2009, at 6:17 AM, Duncan Sands wrote: > you need to use a separate objects directory and not build directly > in the llvm-gcc tree. For some reason the Apple people placed a file > GNUmakefile in the tree which "make" chooses in preference to the > Makefile > produced by configuring. Personally I would like to see GNUmakefile > deleted. My take, you can test an environment variable called RC_RELEASE in the GNUmakefile and use it, if set, and if it isn't set,...

On Saturday 04 April 2009 19:12:55 Mike Stump wrote: > On Apr 4, 2009, at 6:17 AM, Duncan Sands wrote: > > you need to use a separate objects directory and not build directly > > in the llvm-gcc tree. For some reason the Apple people placed a file > > GNUmakefile in the tree which "make" chooses in preference to the > > Makefile > > produced by configuring. Personally I would like to see GNUmakefile > > deleted. > > My take, you can test an environment variable called RC_RELEASE in the > GNUmakefile and use it, if...

it appears that by default some Apple configuration is assumed, since a simple make complains GNUmakefile:16: /CoreOS/Standard/Standard.make: No such file or directory We started with a subversion checkout, in case it matters. --------------------------------------------------------------------+ Thomas Plum, Plum Hall Inc, 3 Waihona Box 44610, Kamuela HI 96743 USA tplum at plumhall.com .......... TE...

...Saturday 04 April 2009 19:12:55 Mike Stump wrote: >> On Apr 4, 2009, at 6:17 AM, Duncan Sands wrote: >>> you need to use a separate objects directory and not build directly >>> in the llvm-gcc tree. For some reason the Apple people placed a >>> file >>> GNUmakefile in the tree which "make" chooses in preference to the >>> Makefile >>> produced by configuring. Personally I would like to see GNUmakefile >>> deleted. >> >> My take, you can test an environment variable called RC_RELEASE in >> the >>...

Hi Thomas, > it appears that by default some Apple configuration is assumed, since > a simple make complains > > GNUmakefile:16: /CoreOS/Standard/Standard.make: No such file or > directory > > We started with a subversion checkout, in case it matters. you need to use a separate objects directory and not build directly in the llvm-gcc tree. For some reason the Apple people placed a file GNUmakefile in the tre...

On Oct 8, 2009, at 5:18 PM, Mike Stump wrote: > On Oct 8, 2009, at 4:52 PM, Stuart Hastings wrote: >> Currently, to get LLVM to build "Apple-style," it's necessary to >> copy two files (utils/buildit/GNUmakefile and utils/buildit/ >> build_llvm) into the top-level directory. > > Why not: > > $ RC_ARCHS="x86" make > echo Apple Build. > Apple Build. > $ make > echo Standard Build > Standard Build > $ cat Makefile > ifneq ($(RC_ARCHS),) > include Makefile....

Currently, to get LLVM to build "Apple-style," it's necessary to copy two files (utils/buildit/GNUmakefile and utils/buildit/build_llvm) into the top-level directory. This is generally a PITA inside of Apple. (I'll spare you the gory details. :-) I'd like to fix this for Apple, and I want to avoid compromising anybody else's build system. I've never used CMAKE, so I would be...

On Oct 8, 2009, at 4:52 PM, Stuart Hastings wrote: > Currently, to get LLVM to build "Apple-style," it's necessary to > copy two files (utils/buildit/GNUmakefile and utils/buildit/ > build_llvm) into the top-level directory. Why not: $ RC_ARCHS="x86" make echo Apple Build. Apple Build. $ make echo Standard Build Standard Build $ cat Makefile ifneq ($(RC_ARCHS),) include Makefile.apple else all: echo Standard Build endif mrs $ cat Makefile....

Hi, I'm having trouble building the llvm-gcc frontend. I'm working with llvm-gcc4.2-2.5. I'm on 32bit x86 linux. I removed the file GNUmakefile, then built it with: ./configure --enable-languages=c,c++ --with-llvm=~/llvm/backend/llvm-2.5 make ~/llvm/backend/llvm-2.5 is where the backend was untared and built, but not installed. After I'd done this there was a file in host-i686-pc-linux-gnu/gcc called xgcc. If I try to build with th...

...2009, at 8:40 AM, Stuart Hastings wrote: > > On Oct 8, 2009, at 5:18 PM, Mike Stump wrote: > >> On Oct 8, 2009, at 4:52 PM, Stuart Hastings wrote: >>> Currently, to get LLVM to build "Apple-style," it's necessary to >>> copy two files (utils/buildit/GNUmakefile and utils/buildit/ >>> build_llvm) into the top-level directory. >> >> Why not: >> >> $ RC_ARCHS="x86" make >> echo Apple Build. >> Apple Build. >> $ make >> echo Standard Build >> Standard Build >> $ cat Makefile >...

Hi Bill, > We use GNUmakefile to trigger using the build_gcc script. thanks for the explanation, but I still don't understand why it is done this way. Why not just get Apple people to run some script, rather than trying to have "make" automagically do an Apple build? > It's not > ideal, but it'...

On Wed, 11 Jul 2007, Leo Fink wrote: >> You need to build darwin driver to use -arch. Try using build_gcc >> script to configure and build llvm-gcc. > > Well, I guess this task exceeds my expertise. I just thought there > was some obvious mistake I made because a lot of people might be > using llvm-gcc4 as a drop-in to Apple's gcc to build multi- > architecture

On Tue, Apr 7, 2009 at 12:38 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Bill, > >> We use GNUmakefile to trigger using the build_gcc script. > > thanks for the explanation, but I still don't understand why > it is done this way.  Why not just get Apple people to run some > script, rather than trying to have "make" automagically do an > Apple build? > It's more c...

Thanks for the hint, Devang. On Jul 6, 2007, at 7:26 PM, Devang Patel wrote: > You need to build darwin driver to use -arch. Try using build_gcc > script to configure and build llvm-gcc. Well, I guess this task exceeds my expertise. I just thought there was some obvious mistake I made because a lot of people might be using llvm-gcc4 as a drop-in to Apple's gcc to build multi-

...e install" as the first step. The normal GCC makefile has a default target of "all", so a typical GCC build will invoke make with no explicit target or with a target such as "all", "bootstrap", "all-gcc", etc. We could add those targets to the GNUmakefile in a rule that prints a message about building with objdir != srcdir. It looks to me like Apple's build system will always invoke make with an explicit target, so it would be OK to make this new rule be the default target.

Hi Daniel, > I'm having trouble building the llvm-gcc frontend. I'm working with > llvm-gcc4.2-2.5. I'm on 32bit x86 linux. I removed the file GNUmakefile, > then built it with: > > ./configure --enable-languages=c,c++ --with-llvm=~/llvm/backend/llvm-2.5 it's --enable-llvm, not --with-llvm. Ciao, Duncan.

...tings wrote: > >> >> On Oct 8, 2009, at 5:18 PM, Mike Stump wrote: >> >>> On Oct 8, 2009, at 4:52 PM, Stuart Hastings wrote: >>>> Currently, to get LLVM to build "Apple-style," it's necessary to >>>> copy two files (utils/buildit/GNUmakefile and utils/buildit/ >>>> build_llvm) into the top-level directory. >>> >>> Why not: >>> >>> $ RC_ARCHS="x86" make >>> echo Apple Build. >>> Apple Build. >>> $ make >>> echo Standard Build >>> Sta...

I have some cpp-files from another library (boost) in a subdirectory in my src directory (src/boost_src). I include these using the following two lines in my Makevars: SOURCES = $(wildcard *.cpp boost_src/*.cpp) OBJECTS = $(SOURCES:.cpp=.o) However, R CMD check complains about my use of 'wildcard'. How do I handle this without any gnu extensions? Thanks. Jan

...uot; as the first step. > The normal GCC makefile has a default target of "all", so a typical > GCC build will invoke make with no explicit target  or with a target > such as "all", "bootstrap", "all-gcc", etc.  We could add those > targets to the GNUmakefile in a rule that prints a message about > building with objdir != srcdir. > > It looks to me like Apple's build system will always invoke make with > an explicit target, so it would be OK to make this new rule be the > default target. > Good point. I'll investigate to see i...

...s (again) tee_input: Don''t expose the @rd object as a return value exec_cgi: small cleanups README: another note about older Sinatra tee_input: avoid defining a @rd.size method Make TeeInput easier to use test_upload: add tests for chunked encoding GNUmakefile: more stringent error checking in tests test_upload: fix ECONNRESET with 1.9 GNUmakefile: allow TRACER= to be specified for tests test_rails: workaround long-standing 1.9 bug tee_input: avoid rereading fresh data "Fix" tests that break with stream_input=fals...