similar to: [LLVMdev] include/Config/config.h discrepancies between CMake and autofoo builds

On Jan 4, 2011, at 7:45 AM, arrowdodger wrote: > Hello. I see many discrepancies in config.h file generated by CMake and autoheader. > > Most of them are following: > In autofoo-generated config: > /* Define to 1 if you have the `<name>' function. */ > #define HAVE_<name> 1 > but in CMake-generated: > #undef HAVE_<name> > This happens because in

Whoops, phone rang and I forgot to cc to the list before I typed the message. ----- Forwarded Message ---- > From: Samuel Crow <samuraileumas at yahoo.com> > To: Ruben Van Boxem <vanboxem.ruben at gmail.com> > Sent: Wed, January 5, 2011 3:38:21 PM > Subject: Re: [LLVMdev] include/Config/config.h discrepancies between CMake and >autofoo builds > > > >

> > We may just not use those functions anymore - do you have a list of these? > Yes, i've started to make up a list of those functions, but it haven't finished yet. > This is more concerning - maybe it's a windows specific problem that came > along? > Not sure, i haven't look yet for CMake checking code itself. By the way, i'm using FreeBSD. Or to say it

Okay, i've started slowly working. Who can i send patches for review, when they will be ready? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110106/88a7e893/attachment.html>

arrowdodger <6yearold at gmail.com> writes: >> Or to say it with other words: patches welcome. > > So, how should i proceed? Make CMake-generated config to be identical to > autotools one? That would be a good thing. Please note that some checks are a bit tricky. A function that on platform A is on header foo.h on another platform may be on bar.h. Furthermore, cmake's

2011/1/5 Óscar Fuentes <ofv at wanadoo.es>: > Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: > >> Yeah that's the two different ones I mean. Everything MS (intrinsics, >> language features etc...) is purely version-bound, so I don't even get >> why CMake insists on checking every known function prototype of for >> example "recv"

On Jan 5, 2011, at 6:34 AM, Óscar Fuentes wrote: > arrowdodger <6yearold at gmail.com> writes: > >>> Or to say it with other words: patches welcome. >> >> So, how should i proceed? Make CMake-generated config to be identical to >> autotools one? > > That would be a good thing. > > Please note that some checks are a bit tricky. A function that

Eric Christopher <echristo at apple.com> writes: >>> Or cleanup both headers from unused stuff by Eric's >>> suggestion? >> >> I'm not sure this is a good idea (not that it is bad either). Murphy's >> Law says that a function that you remove today will be used tomorrow. > > I meant literally functions that aren't used in the

> contains most of them. If they're non-trivial (like the ones I needed to > add for OSX functionality) that's a different story. FWIW the difference is even more significant on, e.g. mingw32 because process spawning is pretty much expensive and sometimes configure time dominates the compile time :) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics,

Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: > And this is why I don't understand configure checks for windows... There's > only one/two header/library sets... The Windows SDK and MinGW. This info > should be built in IMHO... Although the panorama is not so diverse as the Unix world, there is quite a bit of variation on Windows too. Apart from the

Op 5 jan. 2011 19:33 schreef "Anton Korobeynikov" <anton at korobeynikov.info> het volgende: > > > contains most of them. If they're non-trivial (like the ones I needed to > > add for OSX functionality) that's a different story. > FWIW the difference is even more significant on, e.g. mingw32 because > process spawning is pretty much expensive and

Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: > Yeah that's the two different ones I mean. Everything MS (intrinsics, > language features etc...) is purely version-bound, so I don't even get > why CMake insists on checking every known function prototype of for > example "recv" and for the presence of headers it (or the project > dev!) should know are

On Jan 5, 2011, at 9:58 AM, Óscar Fuentes wrote: > Eric Christopher <echristo at apple.com> writes: > >>>> Or cleanup both headers from unused stuff by Eric's >>>> suggestion? >>> >>> I'm not sure this is a good idea (not that it is bad either). Murphy's >>> Law says that a function that you remove today will be used

2011/1/5 Óscar Fuentes <ofv at wanadoo.es>: > Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: > >> And this is why I don't understand configure checks for windows... There's >> only one/two header/library sets... The Windows SDK and MinGW. This info >> should be built in IMHO... > > Although the panorama is not so diverse as the Unix world,

Hello. When i run llvm-config --libs jit bitreader bitwriter ipo linker engine i get: -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMX86Info -lLLVMLinker -lLLVMArchive -lLLVMipo -lLLVMBitWriter -lLLVMBitReader -lLLVMJIT -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine

I''m at the bloody forehead stage, so I figure it''s time to ask. After installing the robot coop''s memcache-client which everyone apparently recommends, it refuses to work because the rails cache.rb is invoking the read() method on the cache, which it _does not have_. Their library has get() and put() but no read() and write() as rails expects. What gives? Is

The following commit seems to have added a dependency on glu but does no checks to see if it is actually available: commit fa5bf5754d8a2e47d659a3abe5cb59a7b0e304d7 Author: David Reveman <davidr@novell.com> Date: Tue Jan 16 06:07:39 2007 +0100 Project vertices and only update minimum required destination texture region. Some more optimizations should be done here but the current

On Tuesday 07 January 2014 21:04:36 Richard W.M. Jones wrote: > On Tue, Jan 07, 2014 at 04:06:43PM +0100, Pino Toscano wrote: > > diff --git a/daemon/xattr.c b/daemon/xattr.c > > index af8bfd4..97a94d5 100644 > > --- a/daemon/xattr.c > > +++ b/daemon/xattr.c > > @@ -545,8 +545,98 @@ do_lgetxattr (const char *path, const char > > *name, size_t *size_r)>

We've been using the runtimes build for a while now and we're very happy with it. However, with an increasing number of targets, it can be fairly slow and I have noticed that we now spend more time in CMake than in Ninja. There are various ways we could improve things like eliminating unnecessary checks. When running checks like check_c_compiler_flag, check_cxx_compiler_flag or

On May 8, 2009, at 1:02 PM, Chris Lattner wrote: > This goes against our general direction for llvm libraries: they > should generally all be built pic. After reviewing yet more of the Makefile,rules file, I believe ENABLE_PIC is the right thing to check. Currently ENABLE_PIC has to be set to get shared bits built, if the user wants them. Given that, we can use that to control