similar to: [LLVMdev] CMake error on Win32

Aaron Gray <aaronngray.lists at gmail.com> writes: > I am getting the following error from CMake :- > > CMake Error at CMakeLists.txt:227 (set_property): > > set_property given invalid scope CACHE. Valid scopes are GLOBAL, > > DIRECTORY, TARGET, SOURCE, TEST. > > > Can someone familiar with CMake deal with this please, Please upgrade to cmake

Hi Oscar, Is there a way to make it work with CMake 2.6? That is what the public win32 buildbot has and I hate messing around with it. - Daniel On Tue, Aug 3, 2010 at 7:59 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Aaron Gray <aaronngray.lists at gmail.com> writes: > >> I am getting the following error from CMake :- >> >>     CMake Error at

Well, I updated to cmake 2.8.12.2 but the result of changing that COMPILE_FLAGS to COMPILE_OPTIONS is that quotes are applied incorrectly: quotes are added surrounding the entire set of flags rather than around each individual item in the list. Obviously the build doesn't work (with the compiler looking for files named " -m64 ... ") but checking the relevant build command in

Óscar Fuentes <ofv at wanadoo.es> wrote: > I'm a bit wary about this patch. So much complexity for so petty > feature... Maybe the right thing is to determine the scenarios where > people set LLVM_USE_CRT. Maybe all we need is to define another build > type that inherits from Release which uses the debug version of the CRT. > > Anyways, the patch have some issues:

I discovered that I can hack around my particular problem by placing set_property(TARGET clang PROPERTY INTERFACE_LINK_LIBRARIES) at the end of tools/driver/CMakeLists.txt. I'd prefer to fix this properly though, of course. On 12/1/17, 4:18 PM, "llvm-dev on behalf of Shoaib Meenai via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org>

Hi all, I can't seem to get the simplest CMakeLists.txt file working from http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project. Do any of the LLVM projects use `find_package(LLVM REQUIRED CONFIG)`? Should I just be using `llvm-config` directly? http://llvm.org/bugs/show_bug.cgi?id=20884 David

Eli Gottlieb <eligottlieb at gmail.com> writes: > I'm trying to upgrade my LLVM bindings in Java from 2.9 to 3.1. To > do so, I regenerated the JNI bindings from fresh LLVM 3.1 headers, and > did a slight rewrite of my CMakeLists.txt file for building the C > code. > > Problem is, cmake no longer finishes at all. I receive the > following output, and then

Hi again, I'm trying to upgrade my LLVM bindings in Java from 2.9 to 3.1. To do so, I regenerated the JNI bindings from fresh LLVM 3.1 headers, and did a slight rewrite of my CMakeLists.txt file for building the C code. Problem is, cmake no longer finishes at all. I receive the following output, and then it just runs forever (while still responding to a CTRL-C): > eli at

It's dead code, the core handles all this directly now. This also allows us to unexport drm_atomic_helper_connector_set_property. The only special case is nouveau which used one function for both pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2 vtables. But amounts to exactly the same. What is rather strange here is how few drivers set this up, I suspect the earlier patch

It's dead code, the core handles all this directly now. This also allows us to unexport drm_atomic_helper_plane_set_property. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Liviu Dudau <liviu.dudau at arm.com> Cc: Brian Starkey <brian.starkey at arm.com> Cc: Mali DP Maintainers <malidp at foss.arm.com> Cc: Boris Brezillon <boris.brezillon at

It's dead code because this is now handled in the core. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Boris Brezillon <boris.brezillon at free-electrons.com> Cc: Daniel Vetter <daniel.vetter at intel.com> Cc: Jani Nikula <jani.nikula at linux.intel.com> Cc: Sean Paul <seanpaul at chromium.org> Cc: David Airlie <airlied at linux.ie> Cc: Ben

Constructing LLVMBuild project information CMake Error at CMakeLists.txt:299 (message): Unexpected failure executing llvm-build: Traceback (most recent call last): File "C:/OpenSource/llvm/utils/llvm-build/llvm-build", line 3, in <module> import llvmbuild File "C:\OpenSource\llvm\utils\llvm-build\llvmbuild\__init__.py", line 1, in <module> from main import

Óscar Fuentes <ofv at wanadoo.es> wrote: > The following message is a courtesy copy of an article > that has been posted to gmane.comp.compilers.llvm.devel as well. > > nobled <nobled at dreamwidth.org> writes: > > [snip] > > Please move the new code to a new file named > cmake/modules/WindowsCRTControl.cmake and include it from the top level > CMakeLists

A couple of llvm sub-projects have been failing to build for me for a while (compiler-rt asan and util/unittests, at least). It turns out to be due to the fact that some paths on my system include spaces and other special characters, but the the build.ninja file was not generated with correctly quoted strings. Specifically I'm on OS X and the command is setting -isysroot to a location inside

NAKAMURA Takumi wrote: > [CMake] Introduce llvm_add_library(). I recommend moving away from wrappers like this. They indicate that either CMake is not providing the interfaces needed, or not propagating them, or that they exist but are not used. Such wrappers don't parse the arguments in the same way as the wrapped command etc. Wrappers are not good API proxies. Additionally, you put

nobled <nobled at dreamwidth.org> writes: [snip] Please move the new code to a new file named cmake/modules/WindowsCRTControl.cmake and include it from the top level CMakeLists when LLVM_ON_WIN32.

Óscar Fuentes <ofv at wanadoo.es> writes: > Yep, llvm_map_components_to_libraries gets confused by the existence of > both gtest and gtest_main and enters an infinite loop. A workaround is > to not pass "all" to llvm_map_components_to_libraries but a list of > required components. This patch *seems* to fix the problem (cmake regexps are not thoroughly documented):

Hi Takumi, I am not sure if it this change, but recently we started to build LLVMHello.so and BugpointPasses.so on OS X. A few bugpoint tests are failing, because they are looking for a dylib that doesn’t exist. Could you please take a look? Thanks -Juergen On Feb 10, 2014, at 2:34 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Steve, excuse me to respond you partially. >

No, it has the wrong value. I tried it with cmake 2.8.9 and 2.8.12.2. Both of them set the variable to “.so”. On Feb 12, 2014, at 5:29 PM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Juergen, > > Thanks to let me know. I guess r200762 (and r200763) might affect. > > Although I won't check this on darwin box, I suspect the line in > HandleLLVMOptions.cmake;

Hi, I can't reproduce your issue on the LLVM 3.5 release branch or trunk it. Looking at your bug report I think your install is messed up ``` CMake Error at /usr/local/Cellar/llvm/HEAD/share/llvm/cmake/LLVMExports.cmake:6 (set_property): set_property could not find TARGET LLVMSupport. Perhaps it has not yet been created. Call Stack (most recent call first):