CMake | Mirror of CMake upstream repository | Build Tool library
kandi X-RAY | CMake Summary
Support
Quality
Security
License
Reuse
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample Here
CMake Key Features
CMake Examples and Code Snippets
Lines of Code : 23License : Non-SPDX (Apache License 2.0)
Copy
def _expand_cmakedefines(line, cmake_vars): """Expands #cmakedefine declarations, using a dictionary 'cmake_vars'.""" # Handles #cmakedefine lines match = _CMAKE_DEFINE_REGEX.match(line) if match: name = match.group(1) suffix = match.group(2) or "" if name in cmake_vars: return "#define {}{}\n".format(name, _expand_variables(suffix, cmake_vars)) else: return "/* #undef {} */\n".format(name) # Handles #cmakedefine01 lines match = _CMAKE_DEFINE01_REGEX.match(line) if match: name = match.group(1) value = cmake_vars.get(name, "0") return "#define {} {}\n".format(name, value) # Otherwise return the line unchanged. return _expand_variables(line, cmake_vars)Trending Discussions on CMake
Trending Discussions on CMake
QUESTION
I've got a project that is working fine in windows os but when I switched my laptop and opened an existing project in MacBook Pro M1. I'm unable to run an existing android project in MacBook pro M1. first I was getting
Execution failed for task ':app:kaptDevDebugKotlin'. > A failure occurred while executing org.jetbrains.kotlin.gradle.internal.KaptExecution > java.lang.reflect.InvocationTargetException (no error message)
this error was due to the Room database I applied a fix that was adding below library before Room database and also changed my JDK location from file structure from JRE to JDK.
kapt "org.xerial:sqlite-jdbc:3.34.0"
//Room components
kapt "org.xerial:sqlite-jdbc:3.34.0"
implementation "androidx.room:room-ktx:$rootProject.roomVersion"
kapt "androidx.room:room-compiler:$rootProject.roomVersion"
androidTestImplementation "androidx.room:room-testing:$rootProject.roomVersion"
after that now I'm getting an issue which is Unknown host CPU architecture: arm64
there is an SDK in my project that is using this below line.
android {
externalNativeBuild {
ndkBuild {
path 'Android.mk'
}
}
ndkVersion '21.4.7075529'
}
App Gradle
externalNativeBuild {
cmake {
path "src/main/cpp/CMakeLists.txt"
version "3.18.1"
//version "3.10.2"
}
}
[CXX1405] error when building with ndkBuild using /Users/mac/Desktop/Consumer-Android/ime/dictionaries/jnidictionaryv2/Android.mk: Build command failed. Error while executing process /Users/mac/Library/Android/sdk/ndk/21.4.7075529/ndk-build with arguments {NDK_PROJECT_PATH=null APP_BUILD_SCRIPT=/Users/mac/Desktop/Consumer-Android/ime/dictionaries/jnidictionaryv2/Android.mk APP_ABI=arm64-v8a NDK_ALL_ABIS=arm64-v8a NDK_DEBUG=1 APP_PLATFORM=android-21 NDK_OUT=/Users/mac/Desktop/Consumer-Android/ime/dictionaries/jnidictionaryv2/build/intermediates/cxx/Debug/4k4s2lc6/obj NDK_LIBS_OUT=/Users/mac/Desktop/Consumer-Android/ime/dictionaries/jnidictionaryv2/build/intermediates/cxx/Debug/4k4s2lc6/lib APP_SHORT_COMMANDS=false LOCAL_SHORT_COMMANDS=false -B -n} ERROR: Unknown host CPU architecture: arm64
which is causing this issue and whenever I comment on this line
path 'Android.mk'
it starts working fine, is there any way around which will help me run this project with this piece of code without getting this NDK issue?
Update - It seems that Room got fixed in the latest updates, Therefore you may consider updating Room to latest version (2.3.0-alpha01 / 2.4.0-alpha03 or above)
ANSWER
Answered 2022-Apr-04 at 18:41To solve this on a Apple Silicon M1 I found three options
AUse NDK 24
android {
ndkVersion "24.0.8215888"
...
}
You can install it with
echo "y" | sudo ${ANDROID_HOME}/tools/bin/sdkmanager --install 'ndk;24.0.8215888'
or
echo "y" | sudo ${ANDROID_HOME}/sdk/cmdline-tools/latest/bin/sdkmanager --install 'ndk;24.0.8215888'
Depending what where sdkmanager is located
Change your ndk-build to use Rosetta x86. Search for your installed ndk with
find ~ -name ndk-build 2>/dev/null
eg
vi ~/Library/Android/sdk/ndk/22.1.7171670/ndk-build
and change
DIR="$(cd "$(dirname "$0")" && pwd)"
$DIR/build/ndk-build "$@"
to
DIR="$(cd "$(dirname "$0")" && pwd)"
arch -x86_64 /bin/bash $DIR/build/ndk-build "$@"
QUESTION
I'm trying to build multiple projects within one build directory with the following structure:
|------ CMakeLists.txt (The main Cmake)
|
|------ ProjectAPP
| |----- .c/h files
| |----- sdh_config.h
| |----- CMakeList.txt
|
|------ ProjectDFU
| |----- .c/h files
| |----- sdh_config.h
| |----- CMakeList.txt
|
|-------- SDK
| |---- SDK used by both projects
The idea would be to build two independent projects, both built on top of one single SDK. Note that both projects rely on a different configuration of the SDK, done by their respective sdk_config.h.
The main CMakeList.txt looks like this:
cmake_minimum_required(VERSION 3.22)
project(project)
add_dependency(ProjectAPP)
add_dependency(ProjectDFU)
add_custom_target(app DEPENDS ${exec_target_app}
...
)
add_custom_target(dfu DEPENDS ${exec_target_dfu}
...
)
add_custom_target(merge DEPENDS app dfu
...
)
Basically my only use of building the two projects in the same place is that I'm then able to have targets depending on both executables so I can then do something with that.
My problem:
The SDK, cmake based, is fragmented in hundreds of small libraries like this:
add_library(lib INTERFACE
"file1.c"
"file2.c"
)
Most of theses libraries will be used by both projects but with different build parameters (cf. sdk_config.h).
Where I'm at right now, I'm getting the following error:
add_library cannot create target "lib" because another target with the same name already exists.
The existing target is an interface library created in source directory "ProjectAPP".
See documentation for policy CMP0002 for more details.
My question:
What would be the best way to isolate both projects in two different build contexts while still being able to have dependencies on each project at root level?
Thank you in advance for any help.
ANSWER
Answered 2022-Mar-13 at 00:27Answering my own question, I'm not sure if it'ss the best way to handle this but cmake ExternalProject solved my problem.
QUESTION
I am trying to get python 3.10.0 installed on my Apple M1 Silicon.
Installing via asdf venv manager. 3.7.9 and 3.9.4 work without any issues but installing 3.10.0 causes the following error:
Last 10 log lines:
"_libintl_textdomain", referenced from:
__locale_textdomain in libpython3.10.a(_localemodule.o)
__locale_textdomain in libpython3.10.a(_localemodule.o)
ld: symbol(s) not found for architecture x86_64
ld: symbol(s) not found for architecture x86_64
clang: clangerror: linker command failed with exit code 1 (use -v to see invocation)
: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Programs/_testembed] Error 1
make: *** Waiting for unfinished jobs....
make: *** [python.exe] Error 1
cmake version 3.22.0
Apple clang version 13.0.0 (clang-1300.0.29.3) Target: x86_64-apple-darwin21.1.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin
What I tried:
export ARCHFLAGS="-arch arm64"
and all the suggestions from
Can't install Python 3.10.0 with pyenv on MacOS
Thank you so much in advance, it's driving me nuts :-)
ANSWER
Answered 2022-Mar-10 at 21:01- First install gettext:
brew install gettext
- Then export flags:
export LDFLAGS="-L/opt/homebrew/lib"; export CPPFLAGS="-I/opt/homebrew/include"
- Finaly install python:
pyenv install 3.10.0
It worked for me. I found it here https://github.com/pyenv/pyenv/issues/1877#issuecomment-962514298
QUESTION
When I am trying to launch flutter desktop application, this error occurred to me:
"CMake Error at CMakeLists.txt:2 (project):
Generator
Visual Studio 16 2019
could not find any instance of Visual Studio.
Building Windows application...
Exception: Unable to generate build files"
What I did...
1- Installed Visual Studio 2022 with (Desktop development with C++ and Universal Windows Platform development)
2- Run these commands:
flutter config --enable-windows-desktop
flutter create .
flutter run -d windows
Also I tried to use dev channel:
flutter channel dev
flutter upgrade
flutter config--enable-windows-uwp-desktop
And these what I have when I run flutter devices and flutter doctor
flutter devices
4 connected devices: Windows (desktop) • windows • windows-x64 • Microsoft Windows [Version 10.0.22000.318] Windows (UWP) (desktop) • winuwp • windows-uwp-x64 • Chrome (web) • chrome • web-javascript • Google Chrome 94.0.4606.81 Edge (web) • edge • web-javascript • Microsoft Edge 95.0.1020.44
flutter doctor
[√] Flutter (Channel dev, 2.6.0-11.0.pre, on Microsoft Windows [Version 10.0.22000.318], locale en-US)
[√] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
[√] Chrome - develop for the web
[√] Visual Studio - develop for Windows (Visual Studio Community 2022 17.0.0)
[√] Android Studio (version 2020.3)
[√] VS Code (version 1.61.1)
[√] Connected device (4 available)
• No issues found!
ANSWER
Answered 2022-Feb-03 at 20:253rd Feb 2022 Update: The latest version of Flutter, version 2.10 stable, has this issue fixed along with stable desktop support for Windows.
Update: The flutter beta channel (2.9.0-0.1.pre onwards) comes with a fix.
According to this issue on the main flutter repo, Flutter prior to version 2.9 does not support Visual Studio 2022. If you want to build while targeting Windows you'll either have to install VS 2019 alongside 2022 or use this workaround:
The current workaround is : download your appropriate flutter version, edit _cmakeVisualStudioGeneratorIdentifier in https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/windows/build_windows.dart#L25-L28 to your appropriate CMake Visual Studio Generator. You can get the currently available CMake Visual Studio Generators on this page : https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#id13.
By default the _cmakeVisualStudioGeneratorIdentifier comes with CMake Visual Studio 2019 Generator. If you are going to use CMake Visual Studio 2022 Generator - firstly ensure your visual studio 2022 distribution contains Cmake 3.21 or later, refer https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2017%202022.html for details.
To apply these changes on Windows:
- Edit
path\to\flutter\packages\flutter_tools\lib\src\windows\build_windows.dart, and change the constant on line 28 from'Visual Studio 16 2019'to'Visual Studio 17 2022' - Delete
flutter_tools.stampandflutter_tools.snapshotinpath\to\flutter\bin\cache\(to cause flutter to regenerate its build tools with the new source code you changed above) - In the project path, run
flutter cleanto remove cached CMake files referring to the wrong Visual Studio version - In the project path, run
flutter run -d windowsto restart the build (successfully, this time)
QUESTION
How do you get CMake to compile conditionally with Qt4.8 or Qt5? In other words, if Qt5 is available then compile with Qt5. Otherwise if Qt4.8 is available use that.
In my CMake, I have:
find_package(Qt5 COMPONENTS Core Gui Widgets...)
This works fine with my Qt5 builds, but how do I get the same software to build with Qt4.8?
I need something that contains the major version number, eg.:
find_package(Qt $QT_VERSION_MAJOR...)
or to use a condition, such as:
result = find_package(Qt 5...)
if (!result) then find_package(Qt4 ...)
or somehow detect the currently install Qt version.
The error I get for the machine with Qt4.8 installed is (unsurprisingly):
CMake Error at CMakeLists.txt:54 (find_package):
By not providing "FindQt5.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Qt5", but
CMake did not find one.
Could not find a package configuration file provided by "Qt5" with any of
the following names:
Qt5Config.cmake
What is the best approach here?
ANSWER
Answered 2022-Feb-15 at 20:06Automatically selecting an available version of Qt is fairly easy with the NAME option of the find_package command. The problem is that Qt4 and Qt5 have different names for the same modules.
# We first try to find the main module of Qt4, Qt5 or Qt6
find_package(QT NAMES Qt4 Qt5 Qt6 REQUIRED)
set(QT Qt${QT_VERSION_MAJOR})
# We prepare lists of modules and libraries for different
# versions of Qt
if (QT_VERSION_MAJOR EQUAL 4)
set(APP_QT_MODULES QtCore QtNetwork QtGui QtXml)
set(APP_QT_TARGETS Qt4::QtCore Qt4::QtNetwork Qt4::QtGui Qt4::QtXml)
else ()
set(APP_QT_MODULES Core Network PrintSupport Widgets Xml)
set(APP_QT_TARGETS ${QT}::Core ${QT}::Network ${QT}::PrintSupport ${QT}::Widgets ${QT}::Xml)
endif ()
# Here everything is simple - find the modules we need.
find_package(${QT} REQUIRED ${APP_QT_MODULES})
. . .
. . .
# And at last don't forget to add libraries.
add_executable(my_app app.cpp main.cpp window.cpp)
target_link_libraries(my_app ${APP_QT_TARGETS})
Another problem is that Qt functions have different names too, for example qt4_add_resources and qt5_add_resources. And this is a good reason to wonder whether or not you really need Qt4 support in your project.
Update
We can make Qt function aliases (as is done in Qt since version 5.15).
if (QT_VERSION VERSION_LESS 5.15)
macro(qt_wrap_cpp)
${QT}_wrap_cpp(${ARGV})
endmacro()
macro(qt_add_resources)
${QT}_add_resources(${ARGV})
endmacro()
macro(qt_generate_moc)
${QT}_generate_moc(${ARGV})
endmacro()
endif ()
QUESTION
I have been writing C for a decent amount of time, and obviously am aware that C does not have any support for explicit private and public fields within structs. However, I (believe) I have found a relatively clean method of implementing this without the use of any macros or voodoo, and I am looking to gain more insight into possible issues I may have overlooked.
The folder structure isn't all that important here but I'll list it anyway because it gives clarity as to the import names (and is also what CLion generates for me).
- example-project
- cmake-build-debug
- example-lib-name
- include
- example-lib-name
- example-header-file.h
- src
- example-lib-name
- example-source-file.c
- CMakeLists.txt
- CMakeLists.txt
- main.c
Let's say that example-header-file.h contains:
typedef struct ExampleStruct {
int data;
} ExampleStruct;
ExampleStruct* new_example_struct(int, double);
which just contains a definition for a struct and a function that returns a pointer to an ExampleStruct.
Obviously, now if I import ExampleStruct into another file, such as main.c, I will be able to create and return a pointer to an ExampleStruct by calling ExampleStruct* new_struct = new_example_struct(, );, and will be able to access the data property like: new_struct->data.
However, what if I also want private properties in this struct. For example, if I am creating a data structure, I don't want it to be easy to modify the internals of it. I.e. if I've implemented a vector struct with a length property that describes the current number of elements in the vector, I wouldn't want for people to just be able to change that value easily.
So, back to our example struct, let's assume we also want a double field in the struct, that describes some part of internal state that we want to make 'private'.
In our implementation file (example-source-file.c), let's say we have the following code:
#include
#include
typedef struct ExampleStruct {
int data;
double val;
} ExampleStruct;
ExampleStruct* new_example_struct(int data, double val) {
ExampleStruct* new_example_struct = malloc(sizeof(ExampleStruct));
example_struct->data=data;
example_struct->val=val;
return new_example_struct;
}
double get_val(ExampleStruct* e) {
return e->val;
}
This file simply implements that constructor method for getting a new pointer to an ExampleStruct that was defined in the header file. However, this file also defines its own version of ExampleStruct, that has a new member field not present in the header file's definition: double val, as well as a getter which gets that value. Now, if I import the same header file into main.c, which contains:
#include
#include "example-lib-name/example-header-file.h"
int main() {
printf("Hello, World!\n");
ExampleStruct* test = new_example(6, 7.2);
printf("%d\n", test->data); // <-- THIS WORKS
double x = get_val(test); // <-- THIS AND THE LINE BELOW ALSO WORK
printf("%f\n", x); //
// printf("%f\n", test->val); <-- WOULD THROW ERROR `val not present on struct!`
return 0;
}
I tested this a couple times with some different fields and have come to the conclusion that modifying this 'private' field, val, or even accessing it without the getter, would be very difficult without using pointer arithmetic dark magic, and that is the whole point.
Some things I see that may be cause for concern:
- This may make code less readable in the eyes of some, but my IDE has arrow buttons that take me to and from the definition and the implementation, and even without that, a one line comment would provide more than enough documentation to point someone in the direction of where the file is.
Questions I'd like answers on:
- Are there significant performance penalties I may suffer as a result of writing code this way?
- Am I overlooking something that may make this whole ordeal pointless, i.e. is there a simpler way to do this or is this explicitly discouraged, and if so, what are the objective reasons behind it.
Aside: I am not trying to make C into C++, and generally favor the way C does things, but sometimes I really want some encapsulation of data.
ANSWER
Answered 2022-Jan-10 at 22:53Are there significant performance penalties I may suffer as a result of writing code this way?
Probably:
- Heap allocation is expensive, and - today - usually not optimized away even when that is theoretically possible.
- Dereferencing a pointer for member access is expensive; although this might get optimized away with link-time-optimization... if you're lucky.
i.e. is there a simpler way to do this
Well, you could use a slack array of the same size as your private fields, and then you wouldn't need to go through pointers all the time:
#define EXAMPLE_STRUCT_PRIVATE_DATA_SIZE sizeof(double)
typedef struct ExampleStruct {
int data;
_Alignas(max_align_t) private_data[EXAMPLE_STRUCT_PRIVATE_DATA_SIZE];
} ExampleStruct;
This is basically a type-erasure of the private data without hiding the fact that it exists. Now, it's true that someone can overwrite the contents of this array, but it's kind of useless to do it intentionally when you "don't know" what the data means. Also, the private data in the "real" definition will need to have the same, maximal, _AlignAs() as well (if you want the private data not to need to use AlignAs(), you will need to use the real alignment quantum for the type-erased version).
The above is C11. You can sort of do about the same thing by typedef'ing max_align_t yourself, then using an array of max_align_t elements for private data, with an appropriate length to cover the actual size of the private data.
An example of the use of such an approach can be found in CUDA's driver API:
- Parameters for copying a 3D array: CUDA_MEMCPY3D vs
- Parameters for copying a 3D array between two GPU devices: CUDA_MEMCPY3D_peer
The first structure has a pair of reserved void* fields, hiding the fact that it's really the second structure. They could have used an unsigned char array, but it so happens that the private fields are pointer-sized, and void* is also kind of opaque.
QUESTION
Although High Sierra is no longer supported by Homebrew, but I need to install llvm@13 formula as a dependency for other formulas. So I tried to install it this way:
$ brew install llvm
...
==> Downloading https://github.com/llvm/llvm-project/releases/download/llvmorg-13.0.0/llvm-project-13.0.0.src.tar.xz
Already downloaded: /Users/username/Library/Caches/Homebrew/downloads/8fd68fc8f968137c5080826db6e58682326235960fd8469363eb27d0799978ca--llvm-project-13.0.0.src.tar.xz
...
==> Installing llvm
==> cmake -G Unix Makefiles .. -DLLVM_ENABLE_PROJECTS=clang;clang-tools-extra;lld;lldb;mlir;polly -DLLVM_ENABLE_RUNTIMES=compiler-rt;libcxx;libcxxabi;libunwind;openmp -DLLVM_POLLY_L
==> cmake --build .
...
[ 79%] Built target lldELF
make: *** [all] Error 2
An error is occurred after a long time of compilation. I also found this error in ~/Library/Logs/Homebrew/llvm/02.cmake:
/tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm:246:52: error: use of undeclared identifier 'CPU_SUBTYPE_ARM64E'
if (cputype == CPU_TYPE_ARM64 && cpusubtype == CPU_SUBTYPE_ARM64E) {
^
1 error generated.
make[2]: *** [tools/lldb/source/Host/macosx/objcxx/CMakeFiles/lldbHostMacOSXObjCXX.dir/HostInfoMacOSX.mm.o] Error 1
make[1]: *** [tools/lldb/source/Host/macosx/objcxx/CMakeFiles/lldbHostMacOSXObjCXX.dir/all] Error 2
How can I fix that compilation error?
ANSWER
Answered 2021-Nov-26 at 08:27Install llvm with debug mode enabled:
$ brew install --debug llvm
Installation process encounters with the same error mentioned in the question, but some options are provided to fix the issue. Choose option 5:
- raise
- ignore
- backtrace
- irb
- shell
Choose an action: 5
It gives a shell access to the current build directory of llvm formula. Find the current folder:
$ pwd
/private/tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src
Change the location to the build directory:
cd llvm/build
Edit the HostInfoMacOSX.mm and remove the second part of condition:
vi ../../lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
You need to change the line 246 from:
if (cputype == CPU_TYPE_ARM64 && cpusubtype == CPU_SUBTYPE_ARM64E) {
to:
if (cputype == CPU_TYPE_ARM64) {
Then re-run the last command:
$ cmake --build .
It takes some time to be completed:
...
[100%] Linking CXX executable ../../../../bin/lldb-vscode
cd /tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src/llvm/build/tools/lldb/tools/lldb-vscode && /usr/local/Cellar/cmake/3.21.4/bin/cmake -E cmake_link_script CMakeFiles/lldb-v
scode.dir/link.txt --verbose=1
/usr/local/Homebrew/Library/Homebrew/shims/mac/super/clang++ -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wn
o-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-c
lass-memaccess -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wno-deprecated-declarations -Wno-unkn
own-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -O3 -DNDEBUG -Wl,-search_paths_first -Wl,-headerpad_max_install_names -stdlib=libc++ -Wl,-sectcreate,__
TEXT,__info_plist,/tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src/llvm/build/tools/lldb/tools/lldb-vscode/lldb-vscode-Info.plist -Wl,-dead_strip CMakeFiles/lldb-vscode.dir/
lldb-vscode.cpp.o CMakeFiles/lldb-vscode.dir/BreakpointBase.cpp.o CMakeFiles/lldb-vscode.dir/ExceptionBreakpoint.cpp.o CMakeFiles/lldb-vscode.dir/FifoFiles.cpp.o CMakeFiles/lldb-vsc
ode.dir/FunctionBreakpoint.cpp.o CMakeFiles/lldb-vscode.dir/IOStream.cpp.o CMakeFiles/lldb-vscode.dir/JSONUtils.cpp.o CMakeFiles/lldb-vscode.dir/LLDBUtils.cpp.o CMakeFiles/lldb-vsco
de.dir/OutputRedirector.cpp.o CMakeFiles/lldb-vscode.dir/ProgressEvent.cpp.o CMakeFiles/lldb-vscode.dir/RunInTerminal.cpp.o CMakeFiles/lldb-vscode.dir/SourceBreakpoint.cpp.o CMakeFi
les/lldb-vscode.dir/VSCode.cpp.o -o ../../../../bin/lldb-vscode -Wl,-rpath,@loader_path/../lib ../../../../lib/liblldb.13.0.0.dylib -lpthread ../../../../lib/libclang-cpp.dylib ../
../../../lib/libLLVM.dylib
[100%] Built target lldb-vscode
/usr/local/Cellar/cmake/3.21.4/bin/cmake -E cmake_progress_start /tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src/llvm/build/CMakeFiles 0
Then run the install command:
$ cmake --build . --target install
The tail of the result should be:
...
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/lib/cmake/llvm/./CheckAtomic.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/lib/cmake/llvm/./FindSphinx.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/lib/cmake/llvm/./FindGRPC.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/lib/cmake/llvm/./TableGen.cmake
Execute the last command:
$ cmake --build . --target install-xcode-toolchain
The tail of the results should be:
...
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/Toolchains/LLVM13.0.0.xctoolchain//usr/lib/cmake/llvm/./CheckAtomic.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/Toolchains/LLVM13.0.0.xctoolchain//usr/lib/cmake/llvm/./FindSphinx.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/Toolchains/LLVM13.0.0.xctoolchain//usr/lib/cmake/llvm/./FindGRPC.cmake
-- Installing: /usr/local/Cellar/llvm/13.0.0_1/Toolchains/LLVM13.0.0.xctoolchain//usr/lib/cmake/llvm/./TableGen.cmake
Built target install-xcode-toolchain
/usr/local/Cellar/cmake/3.21.4/bin/cmake -E cmake_progress_start /tmp/llvm-20211109-12151-m0zvtm/llvm-project-13.0.0.src/llvm/build/CMakeFiles 0
Then press control+d to return to debug menu. Because the two last commands were run manually, you need to ignore the rest of errors by choosing the option 2:
- raise
- ignore
- backtrace
- irb
- shell
Choose an action: 2
==> cmake --build . --target install
...
cmake
--build
.
--target
install
Error: could not load cache
BuildError: Failed executing: cmake --build . --target install
1. raise
2. ignore
3. backtrace
4. irb
5. shell
Choose an action: 2
==> cmake --build . --target install-xcode-toolchain
...
cmake
--build
.
--target
install-xcode-toolchain
Error: could not load cache
BuildError: Failed executing: cmake --build . --target install-xcode-toolchain
1. raise
2. ignore
3. backtrace
4. irb
5. shell
Choose an action: 2
It will continue to install to the rest:
==> Fixing /usr/local/Cellar/llvm/13.0.0_1/bin/FileCheck permissions from 755 to 555
==> Fixing /usr/local/Cellar/llvm/13.0.0_1/bin/analyze-build permissions from 755 to 555
...
==> Changing dylib ID of /usr/local/Cellar/llvm/13.0.0_1/lib/libunwind.1.0.dylib
from @rpath/libunwind.1.dylib
to /usr/local/opt/llvm/lib/libunwind.1.dylib
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FromPathLoader): loading /usr/local/opt/llvm/.brew/llvm.rb
==> Caveats
To use the bundled libc++ please add the following LDFLAGS:
LDFLAGS="-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib"
llvm is keg-only, which means it was not symlinked into /usr/local,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.
If you need to have llvm first in your PATH, run:
echo 'export PATH="/usr/local/opt/llvm/bin:$PATH"' >> ~/.zshrc
For compilers to find llvm you may need to set:
export LDFLAGS="-L/usr/local/opt/llvm/lib"
export CPPFLAGS="-I/usr/local/opt/llvm/include"
==> Summary
🍺 /usr/local/Cellar/llvm/13.0.0_1: 10,907 files, 1.8GB, built in 1418 minutes 39 seconds
It can be verified this way, the default llvm@10 pre-installed:
$ /usr/bin/clang --version
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
And the new Homebrew version of llvm@13:
$ /usr/local/opt/llvm/bin/clang --version
Homebrew clang version 13.0.0
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin
QUESTION
Recently, Apple has released a library to use Metal directly using C++. The example that I've found online (https://github.com/moritzhof/metal-cpp-examples), works if I copy the source code and follow the steps outlined by Apple (https://developer.apple.com/metal/cpp/) in Xcode. I don't use the included Xcode project files, to avoid any "hidden" settings.
Now I'm trying to get the same example to build using CMake, with this CMakeLists.txt:
cmake_minimum_required(VERSION 3.8)
project(HelloWorld)
set(CMAKE_CXX_STANDARD 17)
include_directories(${PROJECT_SOURCE_DIR}/metal-cpp)
set(SOURCE_FILES metal-cpp-test/main.cpp metal-cpp-test/metal_adder.cpp)
add_executable(program ${SOURCE_FILES})
# specify which libraries to connect
# target_link_libraries(program ${METAL})
# target_link_libraries(program ${FOUNDATION})
# target_link_libraries(program ${QUARTZCORE})
find_library(METAL Metal)
find_library(FOUNDATION Foundation)
find_library(QUARTZCORE QuartzCore)
target_link_libraries(program stdc++ "-framework Metal" "-framework Foundation" "-framework QuartzCore" objc)
It compiles successfully, but the line
auto lib = _device->newDefaultLibrary();
Now seems to return a null-ptr. Any idea what the reason for this could be and how to solve this?
ANSWER
Answered 2022-Jan-08 at 16:39All .metal files in an Xcode project that builds an application are compiled and built into a single default library.
_device->newDefaultLibrary() return a new library object that contains the functions from the default library. This method returns nil if the default library cannot be found.
Since you are not using Xcode, you should manually compile Metal Shading Language source code and build a Metal library.
Then, at runtime, call the newLibrary(filePath, &error) method to retrieve and access your library as a MTL::Library object.
NS::String* filePath = NS::String::string("The full file path to a .metallib file", NS::UTF8StringEncoding);
NS::Error* error;
auto library =_device->newLibrary(filePath, &error);
if(error)
{
}
QUESTION
If we look at the minimal example below,
cmake_minimum_required(VERSION 3.20)
project(example)
add_executable(${PROJECT_NAME} main.cpp test.txt)
Once the executable target is built, it will only rebuild if main.cpp is modified. If test.txt is modified, it wouldn't rebuild because eventhough test.txt is included as a source for the executable target, it isn't used to compile the executable. Is there any way that we can configure cmake so that when test.txt is modified, it will trigger a rebuild?
The real use case for my application is I have a metal file that is associated with an executable target (e.g. add_executable(${PROJECT_NAME} main.cpp mylib.metal)) and I want to generate mylib.metallib along with the example executable when the target is build. I have something like
add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD
COMMAND "the command to compile .metal into .metallib")
but this add_custom_command will only be invoked during the first compilation of the executable target, or whenever main.cpp is modified, I want this add_custom_command to be invoked also when mylib.metal is modified. How can this be done?
ANSWER
Answered 2022-Jan-08 at 01:16One way is to create a custom target and add a custom command to it that will generate your mylib.metallib
cmake_minimum_required(VERSION 3.20)
project(custom_file_target VERSION 1.0.0)
add_executable(main main.cpp) # main target
add_custom_target(
custom
DEPENDS ${CMAKE_BINARY_DIR}/mylib.metallib
)
add_custom_command(
OUTPUT ${CMAKE_BINARY_DIR}/mylib.metallib
COMMAND echo your command that will create mylib.metallib
DEPENDS ${CMAKE_SOURCE_DIR}/mylib.metal
)
add_dependencies(main custom)
You can swap main and custom in the last line depending on what dependency ordering you want (main depends on custom or the other way round).
See also my other answer here: https://stackoverflow.com/a/70626372/8088550
If mylib.metallib is actually linkable you can also think about creating an imported library that depends on your custom target, i.e.
cmake_minimum_required(VERSION 3.20)
project(custom_file_target VERSION 1.0.0)
add_executable(main main.cpp) # main target
add_custom_target(
custom
DEPENDS ${CMAKE_BINARY_DIR}/mylib.metallib
)
add_custom_command(
OUTPUT ${CMAKE_BINARY_DIR}/mylib.metallib
COMMAND echo your command that will create mylib.metallib
DEPENDS ${CMAKE_SOURCE_DIR}/mylib.metal
)
add_library(mylib STATIC IMPORTED)
set_property(
TARGET mylib PROPERTY
IMPORTED_LOCATION ${CMAKE_BINARY_DIR}/mylib.metallib
)
add_dependencies(mylib custom)
target_link_libraries(main PRIVATE mylib)
QUESTION
I'm using a library that I cannot compile for Apple M1, so I have decided to compile it and use it using (Rosetta 2) for x86_64 which I successfully did following this to install brew and clang for x86_64.
However when I compile my project and try to link it against this library I get this error:
ld: warning: ignoring file ..../libapronxx.a, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
...
ld: symbol(s) not found for architecture arm64
I have tried to the set compiler and linker flags ("-arch x86_64") but still got the same problem.
My question is: What is the proper way to build for macOS-x86_64 using cmake on Apple M1 (arm)?
Additional information: I'm using cmake via CLion.
UPDATE: I successfully compiled my project using the following commands:
# install a x86 cmake
arch -x86_64 /usr/local/bin/brew install cmake
...
# in the build directory
arch -x86_64 /usr/local/bin/cmake ..
make
arch -x86_64 ./my_exe
I also specified the architecture for clang using -arch flag
string(APPEND CMAKE_CXX_FLAGS_RELEASE " -arch x86_64 -O3")
string(APPEND CMAKE_CC_FLAGS_RELEASE " -arch x86_64 -O3")
# did the same for debug too
While this work fine, I still don't believe it is the proper way to use cmake to build for macOS-x86_64, in fact I cannot take the advantages of my IDE with all this manual approach.
ANSWER
Answered 2021-Nov-02 at 09:54After checking CMake source code, I found that it is enough to set CMAKE_OSX_ARCHITECTURES to x86_64:
set(CMAKE_OSX_ARCHITECTURES "x86_64")
This is the cleanest way so far to solve this issue, and work straight forward with CLion too.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install CMake
Support
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesExplore Kits - Develop, implement, customize Projects, Custom Functions and Applications with kandi kits
Save this library and start creating your kit
Share this Page
