CMake performance difference: --build --preset vs. --build dir - performance

I have a CMake solution with ~1.5K C/C++ projects/subdirs and I wanted to use CMake presets. This is my CMakePresets.json:
{
"version": 3,
"cmakeMinimumRequired": {
"major": 3,
"minor": 20,
"patch": 1
},
"configurePresets": [
{
"name" : "base" ,
"displayName" : "Base Config Preset" ,
"description" : "Base config using VS2019" ,
"generator" : "Visual Studio 16 2019" ,
"architecture" : {"value":"Win32", "strategy":"set"} ,
"binaryDir" : "G:/.bld" ,
"installDir" : "G:/.dst"
}
],
"buildPresets": [
{
"name" : "base" ,
"displayName" : "Base Build Preset" ,
"description" : "base build preset" ,
"jobs" : 0 ,
"cleanFirst" : true ,
"verbose" : false ,
"configurePreset" : "base"
}
]
}
I observed a significant duration difference (~40%) between the following 2 approaches (both were run in an identical clean context):
Using classic folder syntax to build
cmake --preset=base
cmake --build G:\.bld -j
Using new preset syntax to build
cmake --preset=base
cmake --build --preset=base -j
Both perform similar during CMake config & generate step. The difference appears during build step, after the Microsoft's header is displayed:
Microsoft (R) Build Engine version 16.11.2+f32259642 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Approach 1. does not have any delay until it displays the following output lines. Total time is ~14 minutes
Approach 2. has 5-6 minutes delay before showing next lines from output (but the CPU is under load). The Microsoft's header is displayed again then everything continues normally. Total time is ~20 minutes
The duration difference seems to be, more or less, that initial delay, when nothing is displayed
Shouldn't they be identical?
Could be a bug in CMake or I do something wrong?
OS: Windows 10 64bit, cmake version 3.21.2

Related

Problems debugging mserver5

I have recently started debugging the mserver5 application using vscode and a very comfy plugin for cmake called CMake Tools. Moreover, I am using gcc 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) as a compiler together with the following launch.json debug configuration for mserver5 in vscode:
{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) mserver5 triangleDB",
"type": "cppdbg",
"request": "launch",
// Resolved by CMake Tools:
"program": "${command:cmake.launchTargetPath}",
"args": ["--dbpath=/home/mledl/dbfarm/triangleDB", "--set", "mapi_port=0"],
"stopAtEntry": false,
"cwd": "${workspaceFolder}/build",
"environment": [
{
// add the directory where our target was built to the PATHs
// it gets resolved by CMake Tools:
"name": "PATH",
"value": "$PATH:${command:cmake.launchTargetDirectory}"
},
],
"externalConsole": true,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
{ "description":"In this mode GDB will be attached to both processes after a call to fork() or vfork().",
"text": "-gdb-set detach-on-fork off",
"ignoreFailures": true
},
{ "description": "The new process is debugged after a fork. The parent process runs unimpeded.",
"text": "-gdb-set follow-fork-mode child",
"ignoreFailures": true
}
]
}
]
}
The database I am connecting to (here triangleDB) has been created within a dbfarm using the monetdb application and I am going to connect to it using the mclient application with the default username and password combination monetdb. I can successfully connect to and query my triangleDB when starting it using the monetdb application withing a running dbfarm.
When starting up the mserver5 for debugging from vscode using the above launch.json file and connecting to it using mclient and the monetdb user I cannot authenticate somehow and get the following error printed to the mserver5 logs:
client1: createExceptionInternal: !ERROR: InvalidCredentialsException:checkCredentials:invalid credentials for user 'monetdb'
Does anybody know why mserver5 cannot retrieve the default user? Does it rely on the deamon monetdbd to retrieve the user data from? Can someone tell me what I am missing or how I can efficiently debug the mserver5?
Another point is that I need to set mapi_port=0 in order to make mserver5 bind to available ports since it is opening two mapi connections somehow when debugging with vscode and CLion. The application crashes when using a specific port since the second binding attempt will be on an already use address. The following section shows that two connections are opened when debugging:
# MonetDB 5 server v11.40.0
# This is an unreleased version
# Serving database 'triangleDB', using 24 threads
# Compiled for x86_64-pc-linux-gnu/64bit with 128bit integers
# Found 31.349 GiB available main-memory of which we use 25.549 GiB
# Copyright (c) 1993 - July 2008 CWI.
# Copyright (c) August 2008 - 2021 MonetDB B.V., all rights reserved
# Visit https://www.monetdb.org/ for further information
# Listening for connection requests on mapi:monetdb://localhost:46093/
# Listening for connection requests on mapi:monetdb://localhost:40387/
Thanks in advance for everybody that can help me out on this one. Looking forward to hearing from you and sty safe everyone.
If your database was created using monetdb and you want to start it directly using mserver5, you need to tell mserver5 where the .vaultkey is.
In you dbfarm, do a grep monet_vault_key merovingian.log, copy the whole --set monet_vault_key=/<path-to>/dbfarm/demo/.vaultkey and add this option to the start-up command of your mserver5.
I am giving an additional answer here, because I want to make clear what I had to do in order to debug the mserver5 using vscode and interact with it using the mclient application.
While trying to figure out why certain modules/libraries could not be loaded, I noticed that the GDK kernel is missing an environment variable called monet_mod_path which can be set using the --set monet_mod_path=/usr/local/lib/monetdb5 option for mserver5. The missing monet_mod_path has also been the reason why mserver5 listened on two addresses for a mapi connection.
I am now using the following command to start mserver5 for debugging:
mserver5 --dbpath=/home/mledl/dbfarm/triangleDB --set monet_vault_key=/home/mledl/dbfarm/triangleDB/.vaultkey --set monet_mod_path=/usr/local/lib/monetdb5 --set gdk_nr_threads=24 --set max_clients=64 --set sql_optimizer=default_pipe
A minimal working configuration would be the following one:
mserver5 --dbpath=/path/to/your/db --set monet_vault_key=/path/to/your/db/.vaultkey --set monet_mod_path=/usr/local/lib/monetdb5
Note: I installed the application into default installation directory. If you choose a custom one the monet module path has the following pattern:
monet_mod_path=/path/to/install/lib/monetdb5
I hope this answer will help someone in the future and saves all the investigation time I had to put in.

CMake project using external SDK toolchain file cross-compile error

My goal is to cross-compile an application which exists on Windows using an external SDK toolchain being build on Linux machine in order to have an executable code for my ARM platform
I am using VisualStudio CMake project on Windows machine.
I am using an external SDK in order to cross-compile my C++ program for Linux arm architecture.
I have build this SDK using Yocto project on my Linux machine ( NOT THE ARM PLATFORM ! )
My CMake toolchain file path on my Linux machine is :
/opt/poky-atmel/2.5.3/sysroots/x86_64-pokysdk-linux/usr/share/cmake/OEToolchainConfig.cmake
I can see that there are multiple cross-compilers that may be used by my SDK under this path :
/opt/poky-atmel/2.5.3/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi
I can mention arm-poky-linux-gnueabi-gcc compiler which I want to use to cross-compile my application and execute it on my ARM platform.
Before including the path of this cross-compiler to my VisualStudio CMakeSettings file, I have tried to use it on my Linux machine ( which hosts my SDK ) in order to compile a simple code and execute it on the ARM platform. I have succeded to do that!
A little remarque that I must source and setup the environment in order to export the important paths and variables of the SDK toolchain so I can compile my code.
Now, after I have been sure about the good work of my SDK cross compiler, I have to use it in VisualStudio on my windows machine and that's for the same purpose ( cross compiling my code in order to use it on my ARM architecture ).
After opening a CMake project on VisualStudio and connecting to my Linux system following these steps :
Remote Connection
I have modified all the settings I need in order to achieve my goal.
You can see here my c++ .cpp file code which is using the Boost library :
#include "CMakeProject4.h"
#include <boost/lambda/lambda.hpp>
#include <iostream>
#include <iterator>
#include <algorithm>
using namespace std;
int main()
{
typedef std::istream_iterator<int> in;
std::cout << "Type in any number: ";
std::for_each(
in(std::cin), in(), std::cout
<< (boost::lambda::_1 * 10)
<< "\nType in another number: ");
}
This is my CMakeList.txt :
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED OFF)
set(Boost_USE_STATIC_RUNTIME OFF)
list(APPEND CMAKE_PREFIX_PATH /opt/poky-atmel/2.5.3/sysroots/cortexa5hf-neon-poky-linux-gnueabi/usr/include)
set(Boost_NO_BOOST_CMAKE ON)
message(STATUS "CMAKE_TOOLCHAIN_FILE='${CMAKE_TOOLCHAIN_FILE}'")
set(CROSS_COMPILER_DIR /opt/poky-atmel/2.5.3/sysroots/x86_64-pokysdk-linux/usr)
set(CMAKE_C_COMPILER ${CROSS_COMPILER_DIR}/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc)
set(CMAKE_CXX_COMPILER ${CROSS_COMPILER_DIR}/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc)
message(STATUS "CMAKE_C_COMPILER='${CMAKE_C_COMPILER}'")
message(STATUS "CMAKE_CXX_COMPILER='${CMAKE_CXX_COMPILER}'")
find_package(Boost 1.66.0)
if(Boost_FOUND)
message (STATUS "success!")
add_executable (CMakeProject4 "CMakeProject4.cpp" "CMakeProject4.h")
include_directories(${Boost_INCLUDE_DIRS})
target_link_libraries(CMakeProject4 ${Boost_LIBRARIES})
endif()
This is my CMakeSettings.json file :
{
"configurations": [
{
"addressSanitizerRuntimeFlags": "detect_leaks=0",
"buildCommandArgs": "",
"cmakeCommandArgs": "cmake -DBoost_DEBUG=ON -DCMAKE_CXX_COMPILER=/opt/poky-atmel/2.5.3/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc",
"cmakeExecutable": "/home/ubuntu/CMake/Executable",
"cmakeToolchain": "/opt/poky-atmel/2.5.3/sysroots/x86_64-pokysdk-linux/usr/share/cmake/OEToolchainConfig.cmake",
"configurationType": "RelWithDebInfo",
"ctestCommandArgs": "",
"generator": "Unix Makefiles",
"inheritEnvironments": [ "linux_arm" ],
"name": "Linux-Release",
"remoteBuildRoot": "/home/ubuntu/CMake/RemoteBR",
"remoteCMakeListsRoot": "/home/ubuntu/CMake/RemoteCML",
"remoteCopyBuildOutput": false,
"remoteCopySources": true,
"remoteCopySourcesExclusionList": [ ".vs", ".git", "out" ],
"remoteCopySourcesMethod": "rsync",
"remoteInstallRoot": "/home/ubuntu/CMake/RemoteIL",
"remoteMachineName": "867574967;192.168.1.12 (username=ubuntu, port=22, authentication=PrivateKey)",
"rsyncCommandArgs": "-t --delete --delete-excluded",
"variables": [
{
"name": "Boost_INCLUDE_DIRS",
"value": "/opt/poky-atmel/2.5.3/sysroots/cortexa5hf-neon-poky-linux-gnueabi/usr/include",
"type": "PATH"
},
{
"name": "Boost_LIBRARIES",
"value": "/opt/poky-atmel/2.5.3/sysroots/cortexa5hf-neon-poky-linux-gnueabi/usr/lib",
"type": "PATH"
},
{
"name": "Boost_INCLUDE_DIR",
"value": "/opt/poky-atmel/2.5.3/sysroots/cortexa5hf-neon-poky-linux-gnueabi/usr/include",
"type": "PATH"
}
]
}
]
}
As you can see I am setting my SDK compilers bin paths to CMAKE_CXX_COMPILER variable.
This is also OEToolchainConfig.cmake file which I find on my Linux machine :
set( CMAKE_SYSTEM_NAME Linux )
set( CMAKE_C_FLAGS $ENV{CFLAGS} CACHE STRING "" FORCE )
set( CMAKE_CXX_FLAGS $ENV{CXXFLAGS} CACHE STRING "" FORCE )
set( CMAKE_ASM_FLAGS ${CMAKE_C_FLAGS} CACHE STRING "" FORCE )
set( CMAKE_LDFLAGS_FLAGS ${CMAKE_CXX_FLAGS} CACHE STRING "" FORCE )
set( CMAKE_FIND_ROOT_PATH $ENV{OECORE_TARGET_SYSROOT} $ENV{OECORE_NATIVE_SYSROOT} )
set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER )
set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY )
# Set CMAKE_SYSTEM_PROCESSOR from the sysroot name (assuming processor-distro-os).
if ($ENV{SDKTARGETSYSROOT} MATCHES "/sysroots/([a-zA-Z0-9_-]+)-.+-.+")
set(CMAKE_SYSTEM_PROCESSOR ${CMAKE_MATCH_1})
endif()
# Include the toolchain configuration subscripts
file( GLOB toolchain_config_files "${CMAKE_TOOLCHAIN_FILE}.d/*.cmake" )
foreach(config ${toolchain_config_files})
include(${config})
endforeach()
I have sourced the environment on my Linux machine and then I try to compile.
This is the command I use to compile my code :
cmake -DBoost_DEBUG=ON -DCMAKE_CXX_COMPILER=/opt/poky-atmel/2.5.3/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc
But, this message occurs from CMake saying that the compiler is broken and some other things that CMake can not find :
CMake message
This is my CMakeCache file where you can see what variables ( compilers and other things .. ) used by my project :
CMakeCache
The first thing I guess, the environment was not setup correctly or VisualStudio is not seeing the environment variable after sourcing the environment from my Linux machine. This is just an opinion.
I don't know realy what is the problem here and why I can not compile my code.
I will appreciate your help!
Thank you!
EDIT
I add the log files :
Here is the CMakeError.log file :
CMakeError.log
Here is CMakeOutput.log file :
CMakeOutput.log
My guess here would be that the OEToolchainConfig.cmake file uses environment variables to find e.g. the target sysroot, the $ENV{OECORE_TARGET_SYSROOT} part, and that is why it's not working.
You write that you have sourced the environment-setup script on your linux machine, but that won't have any effect on the environment when you're trying to build from VS from Windows.
Either see if there's a way that you can make the build via VS use the environment script, or simply see what values the environment variables used in OEToolchainConfig.cmake have on the linux machine after sourcing the setup script, and replace the $ENV{} parts of OEToolchainConfig.cmake with the actual values instead.
I had the same problem as you and this post helped find out a solution for this.
Error messages like:
ld: cannot find crt1.o: No such file or directory
are linker errors likely due to not having specified a sysroot in your build command.
In VS 2022 I have been able to cross-compile a simple hello world program.
Here is the relevant section of my CMakePresets.json:
{
"name": "linux-debug",
"displayName": "Linux Debug",
"generator": "Unix Makefiles",
"toolchainFile": "/opt/fslc-framebuffer/2.4.1/sysroots/x86_64-fslcsdk-linux/usr/share/cmake/OEToolchainConfig.cmake",
"environment": {
"CXX": "/opt/fslc-framebuffer/2.4.1/sysroots/x86_64-fslcsdk-linux/usr/bin/arm-fslc-linux-gnueabi/arm-fslc-linux-gnueabi-g++ -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard --sysroot=/opt/fslc-framebuffer/2.4.1/sysroots/armv7at2hf-neon-fslc-linux-gnueabi",
"CFLAGS": "-O2 -pipe -g -feliminate-unused-debug-types",
"CXXFLAGS": "-O2 -pipe -g -feliminate-unused-debug-types",
"OECORE_TARGET_SYSROOT": "/opt/fslc-framebuffer/2.4.1/sysroots/armv7at2hf-neon-fslc-linux-gnueabi",
"OECORE_NATIVE_SYSROOT": "/opt/fslc-framebuffer/2.4.1/sysroots/x86_64-fslcsdk-linux",
"SDKTARGETSYSROOT": "/opt/fslc-framebuffer/2.4.1/sysroots/armv7at2hf-neon-fslc-linux-gnueabi"
},
"binaryDir": "${sourceDir}/out/build/${presetName}",
"installDir": "${sourceDir}/out/install/${presetName}",
"cacheVariables": {
"CMAKE_BUILD_TYPE": "Debug"
},
"condition": {
"type": "equals",
"lhs": "${hostSystemName}",
"rhs": "Linux"
},
"vendor": {
"microsoft.com/VisualStudioRemoteSettings/CMake/1.0": {
"sourceDir": "$env{HOME}/.vs/$ms{projectDirName}"
}
}
}
Note that I added the reference to my toolchain file (key: toolchainFile) and set up the environment variables as needed (these would be set by sourcing your SDK).
So, no need to source the SDK first, just tell VS where to find the toolchainFile and make sure all relevant environment variables are set.

NMAKE : fatal error U1077: '"' : return code '0x1'

I'm trying to create a php extension using c/c++.
I have installed Visual Studio 2019 with modified installation:
only install MSVC v140 - VS 2015 C++ builds tools (v14.00)
Install Workloads Windows
and also downloaded php7.1.28 source.
The following is my file at C:\php-7.1.28\ext\helloworld\
File: config.w32
ARG_ENABLE("helloworld", "helloworld support", "no");
if (PHP_HELLOWORLD == "yes") {
EXTENSION("helloworld", "php_helloworld.c", true);
}
File: php_helloworld.h
// we define Module constants
#define PHP_HELLOWORLD_EXTNAME "php_helloworld"
#define PHP_HELLOWORLD_VERSION "0.0.1"
// then we declare the function to be exported
PHP_FUNCTION(helloworld_php);
File: php_helloworld.c
// include the PHP API itself
#include <php.h>
// then include the header of your extension
#include "php_helloworld.h"
// register our function to the PHP API
// so that PHP knows, which functions are in this module
zend_function_entry helloworld_php_functions[] = {
PHP_FE(helloworld_php, NULL)
{NULL, NULL, NULL}
};
// some pieces of information about our module
zend_module_entry helloworld_php_module_entry = {
STANDARD_MODULE_HEADER,
PHP_HELLOWORLD_EXTNAME,
helloworld_php_functions,
NULL,
NULL,
NULL,
NULL,
NULL,
PHP_HELLOWORLD_VERSION,
STANDARD_MODULE_PROPERTIES
};
// use a macro to output additional C code, to make ext dynamically loadable
ZEND_GET_MODULE(helloworld_php)
// Finally, we implement our "Hello World" function
// this function will be made available to PHP
// and prints to PHP stdout using printf
PHP_FUNCTION(helloworld_php) {
php_printf("Hello World! (from our extension)\n");
}
After I wanna make the extension using php7.1.28 source with compiler MSVC14 (Visual C++ 2015) the following log is my error.
C:\php-7.1.28>nmake
Microsoft (R) Program Maintenance Utility Version 14.00.24245.0
Copyright (C) Microsoft Corporation. All rights reserved.
Recreating build dirs
type ext\pcre\php_pcre.def > C:\php-7.1.28\x64\Release_TS\php7ts.dll.def
"" -h win32\ -r C:\php-7.1.28\x64\Release_TS\ -x C:\php-7.1.28\x64\Release_TS\
win32\build\wsyslog.mc
'-h' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: '"' : return code '0x1'
Stop.
Why am I getting the errors and how can I fix this?
An error like that witnesses the absent Windows 10 SDK. There should be better error messages in the later PHP versions, the tools needed from there are mt.exe and mc.exe.
Other than that, I'd recommend using the documented Visual Studio versions and SDK for better experience.
Thanks

Starting a cmake-built application with administrative priviliges from Visual Studio 2019 on a remote Linux machine

Running IDE-Machine Windows 10 with Visual Studio 2019.
Target-System for debugging is a Ubuntu 18.04.
Using CMake available in Visual Stdio addons.
Test software is the same lib, with the simple_test program, which already leads to the issue (https://github.com/OpenEtherCATsociety/SOEM).
After passing the eth-interface to the built program, it stops with cause it can't get root.
Already tried to pass sudo in the launch.vs.json and also pipe sudo the program.
Tried to change the access to the security permission for the eth-device.
"configurations": [
{
"type": "cppdbg",
"name": "simple_test (test\\linux\\simple_test\\simple_test)",
"project": "CMakeLists.txt",
"projectTarget": "simple_test (test\\linux\\simple_test\\simple_test)",
... // standard setup
"args": [
"enp3s0" //the eth dev I want to use
],
... // standard setup
]
}
The result of the program without root is:
>SOEM (Simple Open EtherCAT Master)
>Simple test
>Starting simple test
>No socket connection on enp3s0
>Execute as root
expecting something like:
>>sudo ~/SOEM/test/linux/simple_test/simple_test enp3s0
>SOEM (Simple Open EtherCAT Master)
>Simple test
>Starting simple test
>ec_init on enp3s0 succeeded.
>2 slaves found and configured.
>Slaves mapped, state to SAFE_OP.
>segments : 1 : 2 0 0 0
>Request operational state for all slaves
>Calculated workcounter 3
>Operational state reached for all slaves.
>^Cocessdata cycle 320, WKC 3 , O: 00 I: 00 T:0
Suggestions about this would be helpful.
Thanks
Okay solved my problem.
You have to pass sudo to the debugger by adding sudo to "debuggerPath": "/usr/bin/gdb" like this:
"debuggerPath": "sudo /usr/bin/gdb"
Resolved for me.

Installing SystemC for VS2013

I am using Windows 10 64-bit machine with Visual Studio Professional 2013 and I want to install SystemC. I downloaded SystemC 2.3.1 and I tried following the "Installation notes" provided but they're slightly outdated.
For one, it says "for VS 2005 and higher on Windows 7 machines" but I am using Windows 10, nevertheless I still tried to follow it. Second, the inclusion of src and lib files cannot be followed as stated there since this method was changed in VS2013. There seems to be no global setting anymore via Tools->Options->Projects->VCC++ directions tab.
Now, I was able to successfully buiold the SystemC.sln solution. However, when I tried to build an example project I got the following error:
LINK : fatal error LNK1104: cannot open file
'C:\Users\Andrew\Downloads\systemc-2.3.1a\systemc-2.3.1a\msvc80\SystemC\Debug.obj'
Even though I think I've correctly specified the src and lib directories in the project properties.
Can anyone explain how to build SystemC with VS2013 on Windows 10 x64?
Update: if you use CMake with Visual Studio, check Setting up a SystemC project with CMake: undefined reference to `sc_core
Currently I have no MSVC2013 installed, so here are steps for MSVC2017 that worked for me.
Download latest SystemC from http://accellera.org/downloads/standards/systemc
Open systemc-2.3.1a\msvc80\SystemC\SystemC.sln in Visual Studio
Visual Studio will offer to update solution, click ok. You can ignore report with warnings.
In VS menu bar set configuration to “Debug“ “Win32”. (In my case was already selected by default)
Build solution (F7)
In console, you may find messages like:
Unknown compiler version - please run the configure tests and report the results
You can ignore them. Solution should build without errors:
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
As a result you will have SystemC.lib in systemc-2.3.1a\msvc80\SystemC\Debug
Now you can create some test SystemC project.
File->New -> Project -> Win32 Console application
Right click on project in solution explorer -> Properties
In Configuration Properties -> C/C++ -> General-> Additional include directories
Add path to: \systemc-2.3.1a\src
In Configuration Properties -> C/C++ -> Code generation -> Runtime Library
Select: Multi-threaded Debug (/MTd)
In Configuration Properties -> C/C++ -> Language -> Enable Run-Time Type Information
Select: Yes (/GR)
In Configuration Properties -> C/C++ -> Command Line -> Additional options
Type: /vmg
In Configuration Properties -> Linker -> General -> Additional Library Directories
Add path to: systemc-2.3.1a\msvc80\SystemC\Debug
In Configuration Properties -> Linker -> Input -> Additional dependencies
Add: SystemC.lib
Now it's time to type some code. For example this "Hello world":
#include "stdafx.h"
struct test_module : sc_module {
SC_HAS_PROCESS(test_module);
test_module(::sc_core::sc_module_name) {
SC_THREAD(test_thread);
}
sc_signal<std::string> message{ "message" };
void test_thread() {
message.write("Hello world!");
wait(1, SC_NS);
cout << message.read() << endl;
sc_stop();
}
};
int sc_main(int argc, char** argv)
{
test_module tmod{ "tmod" };
sc_start();
return 0;
}
In stdafx.h add:
#include <systemc.h>
Build project, it will fail with:
\systemc-2.3.1a\src\systemc.h(120): error C2039: 'gets': is not a member of 'std'
gets was removed from std namespace in latest MSVCs, but it is not really required.
So just open systemc.h and comment out Line 120:
// using std::gets;
In case you got error about sprintf
Add _CRT_SECURE_NO_WARNINGS to list of preprocessor definitions
Build again. Run without debugging (Ctrl+F5). You should see the following introduction test on your console:
SystemC 2.3.1-Accellera --- Feb 1 2017 14:43:06
Copyright (c) 1996-2014 by all Contributors,
ALL RIGHTS RESERVED
Hello world!
Info: /OSCI/SystemC: Simulation stopped by user.
Press any key to continue . . .
Hope that helps

Resources