search for: cmakedefin

...at iterator.h, we can import the necessary defines from config.h. /************************************** ** Created by Kevin from config.h.in ** ***************************************/ +#ifdef LLVM_IMPORT_ITERATOR_CONFIG +/* Define to 1 if you have the `bidirectional_iterator' struct*/ +#cmakedefine HAVE_BI_ITERATOR ${HAVE_BI_ITERATOR} + +/* Define to 1 if you have the standard `iterator' struct */ +#cmakedefine HAVE_STD_ITERATOR ${HAVE_STD_ITERATOR} + +/* Define to 1 if you have the `forward_iterator' struct*/ +#cmakedefine HAVE_FWD_ITERATOR ${HAVE_FWD_ITERATOR} + +#elif defined(LLVM...

Hi Yonggang! On Aug 27, 1:02 pm, 罗勇刚(Yonggang Luo) <luoyongg... at gmail.com> wrote: > Because this patch must be applied in one time so that don't broken > the buildbot system. > So I just submit the configure and cmake at the same time. > Also, this patch add two new file > iterator.h > and > DataTypes.h What do you want to improve exactly? Do you experience

Because this patch must be applied in one time so that don't broken the buildbot system. So I just submit the configure and cmake at the same time. Also, this patch add two new file iterator.h and DataTypes.h for the reason that patch doesn't support for svn's rename mechanics. So I just add these two file and doesn't delete the old history files Because I doesn't get

...ARIABLE}) + set(RESULT_TEXT "success") + else() + set(RESULT_TEXT "failed") + endif() + endif() +endmacro(TEST_VARARRAYS VARIABLE) diff --git a/config.h.cmake b/config.h.cmake new file mode 100644 index 0000000..cbf88b1 --- /dev/null +++ b/config.h.cmake @@ -0,0 +1,23 @@ +#cmakedefine WORDS_BIGENDIAN +#cmakedefine FLOATING_POINT +#cmakedefine FIXED_POINT +#cmakedefine FIXED_POINT_DEBUG +#cmakedefine DISABLE_FLOAT_API +#cmakedefine _USE_SSE +#cmakedefine ARM4_ASM +#cmakedefine ARM5E_ASM +#cmakedefine BFIN_ASM +#cmakedefine TI_C55X +#cmakedefine DISABLE_VBR +#cmakedefine USE_SPEE...

...in Clang's tools/driver/Makefile: +ifdef STP_INSTALL_PREFIX +LDFLAGS += -L$(STP_INSTALL_PREFIX)/lib -lstp +endif To support CMake builds as well, is it sufficient to add the following to config.h.cmake, and expect the user to pass -DWITH_STP_PREFIX= if they would like to use this feature? #cmakedefine STP_C_INTERFACE ${WITH_STP_PREFIX}/include/stp/c_interface.h One potential issue I noticed in writing this patch is that LLVM's config.h and Clang's config.h are both #include-guarded by the CONFIG_H macro, and consequently both cannot be included from the same source file. Perhaps these...

...I prefer to stick to released llvm, I > didn't if the > results of the compilation was usuable ;) > > -- The last time I tried it on OS X, the cmake file did not correctly generate the config.h. (There is a lots of hardcoded value in config.h.cmake that should be replaced by cmakedefine equivalent).

...h HAVE_PTHREAD_MUTEX_LOCK) check_symbol_exists(strtoll stdlib.h HAVE_STRTOLL) diff --git a/include/llvm/Config/config.h.cmake b/include/llvm/Config/config.h.cmake index e5f908a..8709518 100644 --- a/include/llvm/Config/config.h.cmake +++ b/include/llvm/Config/config.h.cmake @@ -231,7 +231,7 @@ #cmakedefine HAVE_MALLOC_MALLOC_H ${HAVE_MALLOC_MALLOC_H} /* Define to 1 if you have the `malloc_zone_statistics' function. */ -#undef HAVE_MALLOC_ZONE_STATISTICS +#cmakedefine HAVE_MALLOC_ZONE_STATISTICS ${HAVE_MALLOC_ZONE_STATISTICS} /* Define to 1 if you have the `memcpy' function. */ #undef...

On Friday 24 October 2008, Óscar Fuentes wrote: > Apart from me, I only know of one person that tried CMake, and it was by > accident. Well I tried it on linux, and it sounds like it worked. Well llvm was build without error, but since I prefer to stick to released llvm, I didn't if the results of the compilation was usuable ;) -- Cyrille Berger

Mike Stump <mrs at apple.com> writes: > On Oct 23, 2008, at 5:04 PM, Óscar Fuentes wrote: >> Now tblgen.exe builds fine with my CMake build system. Guess it is >> the same case for the VC++ project files. > > Oh, does clang building work with CMake? If not, wanna cons it > up? :-) Thanks. Giving a compelling reason why you'll like to build clang using

I don't know since when, but this file has been changed to remove all the trickery (aka defines) needed for MinGW-w64 (and probably everything else that as forgotten) to succesfully compile it. Attached is a patch that reintroduces the compiler checking. I would like to see this in LLVM 3.0, otherwise (by the looks of the reintroduced code) anything newer than _MSC_VER_1500 will be broken.

...clude/llvm/Config/config.h.cmake b/include/llvm/Config/config.h.cmake > index ff41d75373c..cdc14aebe0f 100644 > --- a/include/llvm/Config/config.h.cmake > +++ b/include/llvm/Config/config.h.cmake > @@ -384,6 +384,9 @@ > /* Define if we have the oprofile JIT-support library */ > #cmakedefine01 LLVM_USE_OPROFILE > > +/* Define if we have the perf JIT-support library */ > +#cmakedefine01 LLVM_USE_PERF > + > /* LLVM version information */ > #cmakedefine LLVM_VERSION_INFO "${LLVM_VERSION_INFO}" > > diff --git a/include/llvm/Config/llvm-config.h.cmak...

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that