A gitlab-runner configuration script .gitlab-ci.yml, for execution in the Powershell:
windows:
tags:
- windows
stage: build
script:
- New-Item -ItemType "directory" -Confirm:$false -Force:$true -Name "build"
- cd build
- cmd.exe "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat"
- cmake -G "Visual Studio 15 2017" -A x64 -T host=x64 -B. ..
- cmake -j8 --build . --config Debug
- ctest -j4
results in
$ cmd.exe "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat"
[...]
-- Configuring done
-- Generating done
-- Build files have been written to: C:/gitlab-runner/builds/xxxxxxxx/build
$ cmake -j8 --build . --config Debug
CMake Error: The source directory "C:/gitlab-runner/builds/xxxxxxxx/build/Debug" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
ERROR: Job failed: exit status 1
How to resolve this conflict between the configure step (cmake) and
the build step (cmake --build)?
The latter won't work without the option --config Debug;
but if that option is given, then it looks for a nonexistent directory.
Same problem with --config Release.
Disclosure: cross-posting from the CMake mailing list.
The ordering of command line arguments to cmake matters in this case. For build mode, the --build option must be the first one listed, but the -j8 option has been put before it. Change the build command to the following and it should work:
cmake --build . --config Debug -j8
The ordering requirement is documented for the --build option in the Build A Project section of the cmake manual.
Related
I tried using a demo to compile tbb in my project.
Link of the demo https://www.selectiveintellect.net/blog/2016/7/29/using-cmake-to-add-third-party-libraries-to-your-project-1
IDE for me is VS2013 and get an error about command 'make'
Performing build step for 'tbb44'
2> CMake Error at F:/CPPs/FAsT-Match-master/build/tbb44/src/tbb44-stamp/tbb44-build-Debug.cmake:49 (message):
2> Command failed: 2
2>
2> 'make' 'tbb_build_prefix=tbb44'
The original command is generated via tbb.cmake, for which it looks like
ExternalProject_Add(${TBB_PREFIX}
PREFIX ${TBB_PREFIX}
URL ${TBB_URL}
URL_MD5 ${TBB_URL_MD5}
CONFIGURE_COMMAND ""
# BUILD_COMMAND ${TBB_MAKE} -j${NCPU} tbb_build_prefix=${TBB_PREFIX}
BUILD_COMMAND ${TBB_MAKE} tbb_build_prefix=${TBB_PREFIX}
The one commented is the original and the one behind is modified.
Is this the problem of MSVC?
That blog post is just completely wrong. TBB comes with its own CMake build now, so there's absolutely no reason to go through ExternalProject like this.
Here's how I built it from source, using Visual Studio 2019 (the instructions should be pretty much the same). From a developer command prompt, using CMake 3.20:
D:\>git clone https://github.com/oneapi-src/oneTBB
D:\>cmake -S oneTBB -B oneTBB-build -DTBB_TEST=OFF
D:\>cmake --build oneTBB-build --config Release
D:\>cmake --build oneTBB-build --config Debug
D:\>cmake --install oneTBB-build --prefix oneTBB-install --config Release
D:\>cmake --install oneTBB-build --prefix oneTBB-install --config Debug
Setting TBB_TEST to OFF saves a lot of time waiting on TBB's tests to build. These commands install the Debug and Release binaries to D:\oneTBB-install. Of course, you can place this folder anywhere you like.
Once this is done, you may use your new TBB build from your project like so:
cmake_minimum_required(VERSION 3.20)
project(TBB-test)
find_package(TBB REQUIRED)
add_executable(main main.cpp)
target_link_libraries(main PRIVATE TBB::tbb)
The TBB package also includes libraries TBB::tbbmalloc and TBB::tbbmalloc_proxy.
When you build your project, you may point find_package to your TBB installation by setting the CMake variable TBB_ROOT to D:/oneTBB-install at the command line via:
D:\>cmake -S myProject -B myProject-build -DTBB_ROOT=D:/oneTBB-install
I had downloaded the files for MongoDB's C drivers and appear to have successfully compiled and installed them according to the publisher's instructions, using Visual Studio 2019 Community. However, after several attempts, the resulting mongoc-1.0.dll continues to fail to register with regsvr32.exe.
I've run the command as administrator, from the system32 folder, as well as the syswow64 folder, with and without the full path to the library, but it keeps throwing either the module failed to load error, or the module was loaded but the entry-point DllRegisterServer was not found.
Here are the three attempts, all of which competed without errors:
attempt 1:
cmake -G "Visual Studio 16 2019" \ "-DCMAKE_INSTALL_PREFIX=E:\mongo\mongo-cxx-driver" \ "-DCMAKE_PREFIX_PATH=E:\mongo\mongo-cxx-driver" \ ..
cmake --build . --config RelWithDebInfo
cmake --build . --config RelWithDebInfo --target install
attempt 2:
cmake -G "Visual Studio 16 2019" \ "-DCMAKE_INSTALL_PREFIX=E:\mongo\mongo-cxx-driver" \ "-DCMAKE_PREFIX_PATH=E:\mongo\mongo-cxx-driver" \ ..
cmake --build . --config Release
cmake --build . --config Release--target install
attempt 3:
cmake -DCMAKE_BUILD_TYPE=Release \ -DLIBBSON_DIR=E:\mongo\mongo-c-driver-1.17.4\src\libbson \ -DLIBMONGOC_DIR=E:\mongo\mongo-c-driver-1.17.4\src\mongoc \ -DCMAKE_INSTALL_PREFIX=E:\mongo\mongo-cxx-driver ..
msbuild.exe ALL_BUILD.vcxproj
msbuild.exe INSTALL.vcxproj
What could I be doing wrong? TIA.
UPDATE: Dependency Walker showed these errors:
At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
At least one delay-load dependency module was not found.
I have no clue how to proceed. Any assistance is appreciated.
Its been a While that I tried to build clang from source code.
I tried with 2 platforms
a> Ubuntu
b> Windows
I am following the link http://clang.llvm.org/docs/LibASTMatchersTutorial.html
Ubuntu
$ mkdir build
$ cd build
$ cmake -GNinja -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ /path/to/source/llvm
After this in build directory ninja.build files generated along with some more folder
$ ninja after this command inside build directory bin folder can be seen and it contains all the clang executables clang,clang++,clang-check and many more.
Windows
I tried every option that is available to build clang from source
I am trying on developer command prompt and also I am having VS Express edition
> mkdir build
> cd build
> cmake -GNinja -DCMAKE_BUILD_TYPE=release -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ path-to-llvm
It throws error
Host compiler appears to require libatomic,but cannot find it.
So I tried in the another way by making DCMAKE_CXX_COMPILER and DCMAKE_C_COMPILER as clang-cl.exe
> cmake -GNinja -DCMAKE_BUILD_TYPE=release -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" -DCMAKE_C_COMPILER=clang-cl.exe -DCMAKE_CXX_COMPILER=clang-cl.exe path-to-llvm
It didnt show any error at first but later while building
atlbase.h file not found
Why it is that much difficult to build clang from source on windows.?
Is this the correct procedure that I am doing?
Kindly help with any solution.
Atom Build package uses .atom-build.yml file to specify project build targets, so I created simple .atom-build.yml to suit my needs. Everything works fine, except one small part. Below its context:
targets:
Run CMake for Windows:
cmd: "cmake"
atomCommandName: "Create Makefiles with CMake"
args:
- "-Bbuild"
- "-H."
- "-G\"MinGW Makefiles\""
In this particular target I'd like to envoke cmake, as Build CMake is not working, or I have no idea how to use it. When used, Build package runs cmd /C to run command written after cmd: with arguments args:. Thus, call shown in Atom is:
cmd /C cmake -Bbuild -H. -G"MinGW Makefiles"
With -G option I define target make enviroment, which is NMake Makefiles by default and I'd like to have MinGW Makefiles. After running target above, cmake throws error:
CMake Error: Could not create named generator "MinGW
... and lists all available generators. Clearly, space in MinGW Makefiles makes Makefiles being understood as next argument. I tried escaping it with \ and ^, but it's not working. Also, I tried moving args to cmd field, as it would run from single command line call.
My question is: how to run cmake target as above using Atom Build package with -G option passed to cmake properly?
EDIT:
With '-G "MinGW Makefiles"' error persists.
With "-G ""MinGW Makefiles""" Atom throws error:
bad indentation of a sequence entry at line 15, column 19:
- "-G""MinGW Makefiles"""
^
I came across your post when I searched a solution for a similar problem. I was trying to add the makefile targets as commands. After many trails, finally I got it working.
cmd: "C:/WinAVR-20100110/utils/bin/make.exe all"
name: all
errorMatch:
- (?<file>[0-9a-zA-Z_]+\\.+[cC]):(?<line>\\d+):\\s+(?<message>.+)
targets:
build all:
cmd: "C:/WinAVR-20100110/utils/bin/make.exe all"
clean and rebuild:
cmd: "C:/WinAVR-20100110/utils/bin/make.exe rebuild"
clear artifacts:
cmd: "C:/WinAVR-20100110/utils/bin/make.exe clean"
The idea here is to pass the arguments as part of command itself not as a separate argument.
I found other way to run cmake with parameters as above. I created PreLoad.cmake file, consisting:
set (CMAKE_MAKE_PROGRAM "C:/Program\ Files\ (x86)/GnuWin32/bin/make.exe" CACHE INTERNAL "" FORCE)
set (CMAKE_GENERATOR "MinGW Makefiles" CACHE INTERNAL "" FORCE)
set (EXECUTABLE_OUTPUT_PATH "build" CACHE INTERNAL "" FORCE)
This file is envoked by cmake before CMakeLists.txt, so it overrides default cmake settings. Secondly, I modified .atom-build.yml:
cmd: "g++"
atomCommandName: "Compile and run with g++"
name: "Compile and run single file C++ project"
args:
- "{FILE_ACTIVE}"
- "-o {FILE_ACTIVE_PATH}/application.exe &&"
- "{FILE_ACTIVE_PATH}/application.exe"
targets:
Run CMake:
cmd: "cmake ."
atomCommandName: "Create Makefiles with CMake"
Build Makefile project:
atomCommandName: "Make all"
cmd: "make"
args:
- "-j4"
- "all"
Run application:
atomCommandName: "Run application"
cmd: "{FILE_ACTIVE_PATH}/build/application.exe"
Full CMake build:
atomCommandName: "Full CMake build"
cmd: "cmake . && make -j4 all && {FILE_ACTIVE_PATH}/build/application.exe"
Works almost perfect - Atom Build package does not support input.
Running:
cmd /C cmake -Bbuild -H. -G"MinGW Makefiles" -DCMAKE_MAKE_PROGRAM=make
directly from command prompt (or without cmd /C), works. Yet from Atom I get:
The system cannot find the path specified.
which is cmd error. I have no idea why it persists.
I am trying to build a project in Release mode. By default it is built in debug mode. I am setting the variable CMAKE_BUILD_TYPE to "Release" in CMakeLists.txt. But it is still building the project in debug mode.
When I pass "Release" as the build type in the CMake command, it still does not work.
The CMake command that I am using is:
cmake -G"Visual Studio 10" -DCMAKE_BUILD_TYPE=Release
-H"source_path" -B"Build path"
Please provide a solution if any.
To change the build type, on Windows, it must be done at build time:
cmake --build {DIR} --config Release
By default it's Debug. I'm still looking for a way of changing this default. CMAKE_BUILD_TYPE doesn't work of course, and tweaking CMAKE_CONFIGURATION_TYPES doesn't work either, obviously for the same reason, they only apply for Unix makefiles, not for Visual projects.
I checked it with Visual Studio 2015 and cmake 3.3 .
Short answer
Link
cmake --build {BUILD_DIR_PATH} --target ALL_BUILD --config {BUILD_TYPE}
Example
cmake --build . --target ALL_BUILD --config Release
Long answer
cmake -G{GENERATOR_NAME} -B{BUILD_DIR_PATH} -H{SOURCE_DIR_PATH}
cmake --build {BUILD_DIR_PATH} --target ALL_BUILD --config {BUILD_TYPE}
Example
cmake -GVisual Studio 14 -Bbuild/win32/x86 -H.
cmake --build build/win32/x86 --target ALL_BUILD --config Release
Additional info
"-G" - specifies the generator name
"-B" - specifies path to the build folder
"-H" - specifies path to the source folder
You cannot set the default build type for Visual Studio from the command line.
CMake's Visual Studio Generators will generate the four standard profiles (Debug, RelWithDebInfo, MinSizeRel and Release) and you have to choose the one you want to build from within VS. This is because the information about the active configuration is not part of the project files generated by CMake, but part of the .suo file generated by VS.
If you want an automated build of a particular configuration, use MSBuild instead of VS which allows you to specify a configuration on the command line.
Tried the things below which worked for me to build the binaries in release/debug mode in Windows.
Added the following line in the root CMakeLists.txt file, just above the project command:
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_BUILD_TYPE} CACHE STRING "" FORCE)
Used the following command for setting the release mode configuration:
cmake -DCMAKE_BUILD_TYPE=Release ..
Used this command to build the same in Release mode:
cmake --build . --config Release
You can repeat the same procedure for debug mode as well, it works.
Bit late, but I found this worked for me and was quite clean:
This means that just calling cmake builds in release mode, but if you want debug mode just call cmake -DCMAKE_BUILD_TYPE=Debug
if(NOT CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE "Release" CACHE STRING "Choose Release or Debug" FORCE)
endif()
If your generator is a single-config generator like "Unix Makefiles" or "Ninja", then the build type is specified by the CMAKE_BUILD_TYPE variable, which can be set in the configure command by using -DCMAKE_BUILD_TYPE:STRING=Release.
For multi-config generators like the Visual Studio generators and "Ninja Multi-Config", the config to build is specified in the build command using the --config argument argument like --config Release. A default value can currently be specified at configure time for the Ninja Multi-Config generator by setting the value of the CMAKE_DEFAULT_BUILD_TYPE variable, which will be used if the --config argument isn't passed to the build command. At the current time, a default cannot be set for Visual Studio generators.
Use it as you do it but in the root cmake file add the following before the project keyword
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_BUILD_TYPE} CACHE STRING "" FORCE)
PROJECT(MY_PROJECT)#It's here just to show where you should add it.