I have quickly tried the "sub_string_finder" example working with CMake, Visual Studio 2015, Windows, and https://github.com/01org/tbb (I have Strawberry Perl installed.)
I am attempting to utilize the TBBBuild.cmake
in another project from this Github repository from intel.
(So I cloned the repository, and trying to run CMake)
My CMakeLists.txt is simple and looks like
cmake_minimum_required(VERSION 3.0.0 FATAL_ERROR)
project(sub_string_finder CXX)
include(${TBB_ROOT}/cmake/TBBBuild.cmake)
# Build Intel TBB with enabled Community Preview Features (CPF).
tbb_build(TBB_ROOT ${TBB_ROOT} CONFIG_DIR TBB_DIR MAKE_ARGS tbb_cpf=1)
#add_executable(sub_string_finder sub_string_finder.cpp)
find_package(TBB REQUIRED tbb_preview)
#target_link_libraries(sub_string_finder ${TBB_IMPORTED_TARGETS})
(Note I'm not even doing anything fancy yet like add an executable to test TBB, just trying to configure / generate a project in CMake. This should build the TBB libraries for me, so I can link them later, and all I am trying to do here.)
This the error I get:
Building Intel TBB: C:/Strawberry/c/bin/gmake.exe -j16 tbb_build_prefix=tbb_cmake_build_subdir tbb_build_dir=C:/Users/ME/Desktop/TESTTBB/tbb/examples/GettingStarted/sub_string_finder/build/tbb_cmake_build compiler=cl tbb_cpf=1
Building is unsuccessful (2): C:/Users/ME/Desktop/TESTTBB/tbb/./build/Makefile.tbb:32: CONFIG: cfg=debug arch=unknown compiler=cl target=windows runtime=unknown
process_begin: CreateProcess(NULL, cl /nologo /Foconcurrent_hash_map.obj /c /MDd /Od /Ob0 /Zi /EHsc /GR /Zc:forScope /Zc:wchar_t /DTBB_USE_DEBUG /D__TBB_LIB_NAME=tbb_preview_debug.lib /DDO_ITT_NOTIFY /GS /DUSE_WINTHREAD /D_CRT_SECURE_NO_DEPRECATE /D_WIN32_WINNT=0x0502 /D__TBB_BUILD=1 /W4 /D__TBB_CPF_BUILD=1 /IC:/Users/ME/Desktop/TESTTBB/tbb/./src /IC:/Users/ME/Desktop/TESTTBB/tbb/./src/rml/include /IC:/Users/ME/Desktop/TESTTBB/tbb/./include C:/Users/ME/Desktop/TESTTBB/tbb/./src/tbb/concurrent_hash_map.cpp, ...) failed.
make (e=2): The system cannot find the file specified.
gmake.exe[1]: *** [C:/Users/ME/Desktop/TESTTBB/tbb/./build/common_rules.inc:76: concurrent_hash_map.obj] Error 2
gmake.exe: *** [Makefile:32: tbb] Error 2
So it is not getting past the
tbb_build(TBB_ROOT ${TBB_ROOT} CONFIG_DIR TBB_DIR MAKE_ARGS tbb_cpf=1)
line of the CMakeLists file.
Inside the TBBBuild there look to be hooks for windows, MSVC, but still having issues with this basic example.
I call the command with the basic
cmake -DTBB_ROOT=c:/libraries/tbb
(where I cloned TBB)
Related
I my library I use boost's float128 wrapper therefore changing the compiler is not an option.
Following Intel's developer guide I added find_package(IntelDPCPP REQUIRED) to my CMakeLists.txt and ran cmake -DCMAKE_C_COMPILER=icx -DCMAKE_CXX_COMPILER=icx -GNinja on the VS 2022 terminal. I get the following error message
Found package configuration file:
C:/Program Files (x86)/Intel/oneAPI/compiler/latest/windows/IntelDPCPP/IntelDPCPPConfig.cmake
but it set IntelDPCPP_FOUND to FALSE so package "IntelDPCPP" is considered
to be NOT FOUND. Reason given by package:
Unsupported compiler family and compiler icx!!
Anyone with a similar issue that can help out?
EDIT: as suggested by #Botje here the output information relevant to this case
IntelDPCPPConfig.cmake(84): string(COMPARE EQUAL ${CMAKE_CXX_COMPILER} nocmplr )
IntelDPCPPConfig.cmake(85): if(nocmplr)
IntelDPCPPConfig.cmake(93): if(NOT x${CMAKE_CXX_COMPILER_ID} STREQUAL xClang AND NOT x${CMAKE_CXX_COMPILER_ID} STREQUAL xIntelLLVM )
IntelDPCPPConfig.cmake(95): set(IntelDPCPP_FOUND False )
This is a known issue, it will be fixed in the OneAPI 2023.1 release.
You can try reversing the order of find_package and project or removing find_package(IntelDPCPP REQUIRED) in CMakeLists.txt. Because CMake identifies and sets up all the compiler-related variables when the project() is called.
Also, you can set the compiler option for the DPC++ compiler in CMakeLists.txt using the below command.
set(CMAKE_CXX_COMPILER dpcpp)
I am having a problem compiling a project with CUDA on VS2017 c++.
I can get rid of this error by just changing the line in
Properties->CUDA C/C++->Command Line-> Additional Options:
%(AdditionalOptions) -Zi /W3 /wd4005 /wd4003 /wd4996 /nologo -Xcompiler="/EHsc -Zi -Ob0"
changed to
%(AdditionalOptions) -Xcompiler="/EHsc -Ob2"
After changing this option, the project compiles without any errors.
My Question is, how can I do it from CMAKE so that I don't have to change this property every time I regenerate the project?
Your .sln file is generated from cmake. You can use cmake-gui.exe to load the cmake cache file and query strings, then override that string in your CMakeLists.txt.
For your case, you would like to remove the annoying "/W3 /wd4005 /wd4003 /wd4996 /nologo " options. You can do like this:
Here, I open cmake-gui.exe, fillin the source folder and build folder of your project, and type "w3" in search box, and get "CMAKE_C_FLAGS". So you can override "CMAKE_C_FLAGS" in your CMakeLists.txt:
set(CMAKE_C_FLAGS "") # set it to empty
# you may also replace some options inside it, go and query cmake docs to see how to do that
Then, clean all the previous generated build files and re-cmake.
So I have a bit of an issue with setting up pdbs in cuda when using cmake and visual studio (2013 in the case).
Basically I think I want to do something like :
-Xcompiler "/Fd whatever.pdb"
to each add_cuda_library, but I can only seem to set CUDA_NVCC_FLAGS, CUDA_NVCC_FLAGS_RELEASE, CUDA_NVCC_FLAGS_DEBUG etc globally.
Right now I use
SET(CUDA_NVCC_FLAGS_RELEASE ${CUDA_NVCC_FLAGS}; -Xcompiler "/Fd nvcc_all.pdb")
And this dumps all the symbols into one file.
Problem is sometimes the build breaks when there are concurrent writes to that pdb. I've tried adding /FS, but it doesn't help.
Is there a cmake incantation to allow me to add a per lib cuda pdbs ?
You can try to pass the flags like this:
CUDA_ADD_LIBRARY(foo
...
OPTIONS "/Fd foo.pdb"
)
I'm trying to build the Boost 1_52 library with VS2012. Everything is building fine except for the Date Time dll (boost_date_time-vc110-mt-1_52.dll).
I'm using B2.exe as shown below
b2.exe toolset=msvc-11.0 --build-type=complete stage debug-symbols=on debug-store=database --abbreviate-paths
I've tried using cxxflags="/Y- " because I get other out of date PDB errors, this didn't change anything. I've tried setting Zm100, again no change.
When it gets to the gregorian section, I get a number of failures like shown below
common.mkdir bin.v2\libs\date_time\build\msvc-11.0\debug\debug-store-database\threading-multi
common.mkdir bin.v2\libs\date_time\build\msvc-11.0\debug\debug-store-database\threading-multi\gregorian
compile-c-c++ bin.v2\libs\date_time\build\msvc-11.0\debug\debug-store-database\threading-multi\gregorian\greg_month.obj
greg_month.cpp
libs\date_time\src\gregorian\greg_month.cpp : fatal error C1033: cannot open program database 'd:\boost\source\boost_1_52_0\gregorian\greg_month.pdb'
call "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" x86 >nul
cl /Zm800 -nologo #"bin.v2\libs\date_time\build\msvc-11.0\debug\debug-store-database\threading-multi\gregorian\greg_month.obj.rsp"
The problem is that the build is trying to place the .pdb files for some object files of the date_time library in a non-existent directory.
You can work around the problem by doing:
md gregorian
before performing the build so the directory exists.
I'm not sure yet what the real fix is since the boost build system is more or less a black box to me.
anyone have jsoncpp working on vc90?
they use a build system, Scons, which I have never heard of. I installed the latest Scons, found an undocumented scons.bat, launched a vc90 prompt in my jsoncpp dir, modified the SConstruct file to support a msvc90 target (i copied the boilerplate from the msvc80 platform which was already supported) ran scons.bat platform=msvc90 and got errors:
scons: done reading SConscript files.
scons: Building targets ...
cl /Fobuildscons\msvc90\src\jsontestrunner\main.obj /c src\jsontestrunner\main.c
pp -GR -EHsc /nologo /MT /nologo /Iinclude /I.
main.cpp
c:\projects\docwayhead\wspt_docway_plugins\contrib\jsoncpp-src-0.5.0\include\jso
n\value.h(5) : fatal error C1083: Cannot open include file: 'string': No such fi
le or directory
scons: *** [buildscons\msvc90\src\jsontestrunner\main.obj] Error 2
scons: building terminated because of errors.
i've already put too much effort into getting this to build, and jsoncpp is clearly unmaintained, so i give up for now.
No need to use Scons.
Under the /makefiles/vc71/ you can find a visual studio solution which you can up convert and build.
Modify the msvc90 platform file to make sure VC90 include directories are used when calling cl (clearly not yet the case in the provided command line you provided).
Note that Scons is written using Python and so are its configuration files, so people who know Python around you might be able to help you efficiently, even if they know nothing about scons.
Are you sure your VS command line is working properly? I got it to work just by:
- Adding a msvc90 entry in allowed_values
- copy/pasting the msvc80 section later and modifying it to use env['MSVS_VERSION'] = 9.0
I'm using scons 1.3.0.
The scons setup for jsoncpp 0.5.0 does not support VS 9.0 or 10.0 out of the box. You need to first add msvc90 to the allowed_values in the SConstruct line 21, and the to add this section on line 103.
elif platform == 'msvc90':
env['MSVS_VERSION']='9.0'
for tool in ['msvc', 'msvs', 'mslink', 'masm', 'mslib']:
env.Tool( tool )
env['CXXFLAGS']='-GR -EHsc /nologo /MT'
Just replace 9.0 with 10.0 and 90 with 100 for VS 10.0 support.
As of version 0.6.0 of jsoncpp, you can avoid a lot of hassle by using the new Amalgamated version. This is just two .h files and one .cpp file that you compile directly into your projects. It's working great for me so far in VS 9 (and with a few mods I'm now able to compile it with C++Builder 2010 as well -- haven't really tested the result yet).
By the way, I've filed a bug against version 0.6.0-rc2; one line in the Amalgamated version of json.h needs to have a macro name changed.