Windows linux cross platform

Tutorial: Create C++ cross-platform projects in Visual Studio

Visual Studio C and C++ development isn’t just for Windows anymore. This tutorial shows how to use Visual Studio for C++ cross platform development on Windows and Linux. It’s based on CMake, so you don’t have to create or generate Visual Studio projects. When you open a folder that contains a CMakeLists.txt file, Visual Studio configures the IntelliSense and build settings automatically. You can quickly start editing, building, and debugging your code locally on Windows. Then, switch your configuration to do the same on Linux, all from within Visual Studio.

In this tutorial, you learn how to:

• clone an open-source CMake project from GitHub
• open the project in Visual Studio
• build and debug an executable target on Windows
• add a connection to a Linux machine
• build and debug the same target on Linux

Prerequisites

Set up Visual Studio for Cross Platform C++ Development

• First, install Visual Studio and choose the Desktop development with C++ and Linux development with C++ workloads. This minimal install is only 3 GB. Depending on your download speed, installation shouldn’t take more than 10 minutes.

Set up a Linux machine for Cross Platform C++ Development

Visual Studio doesn’t require any specific distribution of Linux. The OS can be running on a physical machine, in a VM, or in the cloud. You could also use the Windows Subsystem for Linux (WSL). However, for this tutorial a graphical environment is required. WSL isn’t recommended here, because it’s intended primarily for command-line operations.

Visual Studio requires these tools on the Linux machine: C++ compilers, gdb, ssh, rsync, make, and zip. On Debian-based systems, you can use this command to install these dependencies:

Visual Studio requires a recent version of CMake on the Linux machine that has server mode enabled (at least 3.8). Microsoft produces a universal build of CMake that you can install on any Linux distro. We recommend you use this build to ensure that you have the latest features. You can get the CMake binaries from the Microsoft fork of the CMake repo on GitHub. Go to that page and download the version that matches the system architecture on your Linux machine, then mark it as an executable:

You can see the options for running the script with -–help . We recommend that you use the –prefix option to specify installing in the /usr path, because /usr/bin is the default location where Visual Studio looks for CMake. The following example shows the Linux-x86_64 script. Change it as needed if you’re using a different target platform.

Git for windows installed on your Windows machine.

A GitHub account.

Clone an open-source CMake project from GitHub

This tutorial uses the Bullet Physics SDK on GitHub. It provides collision detection and physics simulations for many applications. The SDK includes sample executable programs that compile and run without having to write additional code. This tutorial doesn’t modify any of the source code or build scripts. To start, clone the bullet3 repository from GitHub on the machine where you have Visual Studio installed.

On the Visual Studio main menu, choose File > Open > CMake. Navigate to the CMakeLists.txt file in the root of the bullet3 repo you just downloaded.

Open > CMake.» data-linktype=»relative-path»>

As soon as you open the folder, your folder structure becomes visible in the Solution Explorer.

This view shows you exactly what is on disk, not a logical or filtered view. By default, it doesn’t show hidden files.

Choose the Show all files button to see all the files in the folder.

Switch to targets view

When you open a folder that uses CMake, Visual Studio automatically generates the CMake cache. This operation might take a few moments, depending on the size of your project.

In the Output Window, select Show output from and then choose CMake to monitor the status of the cache generation process. When the operation is complete, it says «Target info extraction done».

After this operation completes, IntelliSense is configured. You can build the project, and debug the application. Visual Studio now shows a logical view of the solution, based on the targets specified in the CMakeLists files.

Use the Solutions and Folders button in the Solution Explorer to switch to CMake Targets View.

Here is what that view looks like for the Bullet SDK:

Targets view provides a more intuitive view of what is in this source base. You can see some targets are libraries and others are executables.

Expand a node in CMake Targets View to see its source code files, wherever those files might be located on disk.

Add an explicit Windows x64-Debug configuration

Visual Studio creates a default x64-Debug configuration for Windows. Configurations are how Visual Studio understands what platform target it’s going to use for CMake. The default configuration isn’t represented on disk. When you explicitly add a configuration, Visual Studio creates a file called CMakeSettings.json. It’s populated with settings for all the configurations you specify.

Add a new configuration. Open the Configuration drop-down in the toolbar and select Manage Configurations.

The CMake Settings Editor opens. Select the green plus sign on the left-hand side of the editor to add a new configuration. The Add Configuration to CMakeSettings dialog appears.

This dialog shows all the configurations included with Visual Studio, plus any custom configurations that you create. If you want to continue to use a x64-Debug configuration, that should be the first one you add. Select x64-Debug, and then choose the Select button. Visual Studio creates the CMakeSettings.json file with a configuration for x64-Debug, and saves it to disk. You can use whatever names you like for your configurations by changing the name parameter directly in CMakeSettings.json.

Set a breakpoint, build, and run on Windows

In this step, we’ll debug an example program that demonstrates the Bullet Physics library.

In Solution Explorer, select AppBasicExampleGui and expand it.

Open the file BasicExample.cpp .

Set a breakpoint that gets hit when you click in the running application. The click event is handled in a method within a helper class. To quickly get there:

Select CommonRigidBodyBase that the struct BasicExample is derived from. It’s around line 30.

Right-click and choose Go to Definition. Now you’re in the header CommonRigidBodyBase.h.

In the browser view above your source, you should see that you’re in the CommonRigidBodyBase . To the right, you can select members to examine. Open the drop-down and select mouseButtonCallback to go to the definition of that function in the header.

Place a breakpoint on the first line within this function. It gets hit when you click a mouse button within the window of the application, when run under the Visual Studio debugger.

To launch the application, select the launch drop-down in the toolbar. It’s the one with the green play icon that says «Select Startup Item». In the drop-down, select AppBasicExampleGui.exe. The executable name now displays on the launch button:

Choose the launch button to build the application and necessary dependencies, then launch it with the Visual Studio debugger attached. After a few moments, the running application appears:

Move your mouse into the application window, then click a button to trigger the breakpoint. The breakpoint brings Visual Studio back to the foreground, and the editor shows the line where execution is paused. You can inspect the application variables, objects, threads, and memory, or step through your code interactively. Choose Continue to let the application resume, and then exit it normally. Or, halt execution within Visual Studio by using the stop button.

Add a Linux configuration and connect to the remote machine

Add a Linux configuration. Right-click the CMakeSettings.json file in the Solution Explorer view and select Add Configuration. You see the same Add Configuration to CMakeSettings dialog as before. Select Linux-Debug this time, then save the CMakeSettings.json file (ctrl + s).

Visual Studio 2019 version 16.6 or later Scroll down to the bottom of the CMake Settings Editor and select Show advanced settings. Select Unix Makefiles as the CMake generator, then save the CMakeSettings.json file (ctrl + s).

Select Linux-Debug in the configuration drop-down.

If it’s the first time you’re connecting to a Linux system, the Connect to Remote System dialog appears.

If you’ve already added a remote connection, you can open this window by navigating to Tools > Options > Cross Platform > Connection Manager.

Provide the connection information to your Linux machine and choose Connect. Visual Studio adds that machine as to CMakeSettings.json as your default connection for Linux-Debug. It also pulls down the headers from your remote machine, so you get IntelliSense specific to that remote connection. Next, Visual Studio sends your files to the remote machine and generates the CMake cache on the remote system. These steps may take some time, depending on the speed of your network and power of your remote machine. You’ll know it’s complete when the message «Target info extraction done» appears in the CMake output window.

Set a breakpoint, build, and run on Linux

Because it’s a desktop application, you need to provide some additional configuration information to the debug configuration.

In the CMake Targets view, right-click AppBasicExampleGui and choose Debug and Launch Settings to open the launch.vs.json file that’s in the hidden .vs subfolder. This file is local to your development environment. You can move it into the root of your project if you wish to check it in and save it with your team. In this file, a configuration has been added for AppBasicExampleGui. These default settings work in most cases, but not here. Because it’s a desktop application, you need to provide some additional information to launch the program so you can see it on your Linux machine.

To find the value of the environment variable DISPLAY on your Linux machine, run this command:

In the configuration for AppBasicExampleGui, there’s a parameter array, «pipeArgs». It contains a line: «$«. It’s the command that launches gdb on the remote machine. Visual Studio must export the display into this context before that command runs. For example, if the value of your display is :1 , modify that line as follows:

Launch and debug your application. Open the Select Startup Item drop-down in the toolbar and choose AppBasicExampleGui. Next, either choose the green play icon in the toolbar, or press F5. The application and its dependencies are built on the remote Linux machine, then launched with the Visual Studio debugger attached. On your remote Linux machine, you should see an application window appear.

Move your mouse into the application window, and click a button. The breakpoint is hit. Program execution pauses, Visual Studio comes back to the foreground, and you see your breakpoint. You should also see a Linux Console Window appear in Visual Studio. The window provides output from the remote Linux machine, and it can also accept input for stdin . Like any Visual Studio window, you can dock it where you prefer to see it. Its position is persisted in future sessions.

You can inspect the application variables, objects, threads, memory, and step through your code interactively using Visual Studio. But this time, you’re doing it all on a remote Linux machine instead of your local Windows environment. You can choose Continue to let the application resume and exit normally, or you can choose the stop button, just as with local execution.

Look at the Call Stack window and view the Calls to x11OpenGLWindow since Visual Studio launched the application on Linux.

What you learned

In this tutorial, you cloned a code base directly from GitHub. You built, ran, and debugged it on Windows without modifications. Then you used the same code base, with minor configuration changes, to build, run, and debug on a remote Linux machine.

Next steps

Learn more about configuring and debugging CMake projects in Visual Studio:

Источник

Using Visual Studio for Cross Platform C++ Development Targeting Windows and Linux

November 26th, 2018

A great strength of C++ is the ability to target multiple platforms without sacrificing performance. If you are using the same codebase for multiple targets, then CMake is the most common solution for building your software. You can use Visual Studio for your C++ cross platform development when using CMake without needing to create or generate Visual Studio projects. Just open the folder with your sources in Visual Studio (File > Open Folder). Visual Studio will recognize CMake is being used, then use metadata CMake produces to configure IntelliSense and builds automatically. You can quickly be editing, building and debugging your code locally on Windows, and then switching your configuration to do the same on Linux all from within Visual Studio.

Teams working on these types of code bases may have developers who have different primary operating systems, e.g. some people are on Linux (and may be using the Visual Studio Code editor) and some are on Windows (probably using the Visual Studio IDE). In an environment like this, the choice of tools may be up to the developers themselves. You can use Visual Studio in an environment like this without perturbing your other team members or making changes to your source as is. If or when additional configuration is needed it is saved in flat json files that can be saved locally, or shared in source control with other developers using Visual Studio without impacting developers that are not using it.

Visual Studio isn’t just for Windows C and C++ development anymore. If you follow the tutorial below on your own machine, you will clone an open source project from GitHub, open it in Visual Studio, edit, build and debug on Windows with no changes to the project. Then Visual Studio will add a connection to a Linux machine and edit, build and debug it on that remote machine.

The next section shows you how to setup Visual Studio, followed by a section on how to configure your Linux target, and last the tutorial itself – have fun!

Setting up Visual Studio for Cross Platform C++ Development

First you need to have Visual Studio installed. If you have it installed already confirm that you have the Desktop development with C++ and Linux development with C++ workloads installed. If you don’t have Visual Studio installed use this link to install it with the minimal set of components for this tutorial selected. This minimal install is only a 3GB, depending on your download speed installation should not take more than 10 minutes.

Once that is done you are ready to go on Windows.

Configuring your Linux machine for cross platform C++ development

Visual Studio does not have a requirement for a specific distribution of Linux; use any you would like to. That can be on a physical machine, in a VM, the cloud, or even running on Windows Subsystem for Linux. The tools Visual Studio requires to be present on the Linux machine are: C++ compilers, GDB, ssh, and zip. On Debian based systems you can install these dependencies as follows.

Visual Studio also of course requires CMake. However, it needs a recent version of CMake that has server mode enabled (at least 3.8). Our team produces a universal build of CMake that you can install on any Linux distro. We recommend using this build over what may be in your package manager as it is built from our fork of the CMake source. Using that fork ensures that you have the latest features in case they haven’t made it back up stream. We document how to configure CMake here, and you can get the CMake binaries from here. Go to that page and download the version that matches your system architecture on your Linux machine. Mark it as an executable:

You can see the options for running it with –help. We recommend that you use the –prefix option to specify installing in the /usr/local path as that is the default location Visual Studio looks for CMake at.

Tutorial: Using the Bullet Physics SDK GitHub repo in Visual Studio

Now that you have Visual Studio and a Linux machine ready to go lets walk through getting a real open source C++ project working in Visual Studio targeting Windows and Linux. For this tutorial we are going to use the Bullet Physics SDK on GitHub. This is a library that provides collision detection and physics simulations for a variety of different applications. There are sample executable programs within it to use so we have something to interact with without having to write additional code. You will not have to modify any of this source or build scripts in the steps that follow.

Note that you can use any Linux distro for this tutorial, however using Windows Subsystem for Linux for this one is not a good idea since the executable we are going to run is graphical which is not supported officially there.

Step 1 – Clone and open the bullet3 repo

To start, clone the bullet3 repository from GitHub on the machine where you have Visual Studio installed. If you have git installed on your command line it will be as simple as running git clone wherever you would like to keep this repository.

Now open the root project folder, bullet3, that was created by cloning the repo in Visual Studio. Use the menu option File > Open > Folder which will detect and use the CMakeLists.txt file or you can use File > Open > CMake to select the desired CMakeLists.txt file directly.

You can also clone a git repo directly within Visual Studio which will automatically open the folder when you are done.

Open > CMake» width=»970″ height=»591″ data-srcset=»https://devblogs.microsoft.com/cppblog/wp-content/uploads/sites/9/2019/02/xplat1.png 970w, https://devblogs.microsoft.com/cppblog/wp-content/uploads/sites/9/2019/02/xplat1-300×183.png 300w, https://devblogs.microsoft.com/cppblog/wp-content/uploads/sites/9/2019/02/xplat1-768×468.png 768w» sizes=»(max-width: 970px) 100vw, 970px»/>

As soon as you open the folder your folder structure will be visible in the Solution Explorer.

This view shows you exactly what is on disk, not a logical or filtered view. By default, it does not show hidden files. To see them, select the show all files button in the Solution Explorer.

Step 2 – Use targets view

When you open a folder that uses CMake, Visual Studio will automatically generate the CMake cache. This will take a few moments, or longer depending on the size of your project. The status of this process is placed in the output window. It is complete when you see the message “Target info extraction done”.

After this completes, IntelliSense is configured, the project can build, and you can launch the application and debug it. Visual Studio also now understands the build targets that the CMake project produces. This enables an alternate CMake Targets View that provides a logical view of the solution. Use the Solutions and Folders button in the Solution Explorer to switch to this view.

Here is what that view looks like for the Bullet SDK.

This gives us a more intuitive view of what is in this source base. You can see some targets are libraries and others are executables. You can expand these nodes and see the source that comprises them independent of how it is represented on disk.

Step 3 – Set breakpoint, build and run

For this tutorial, use an executable to get something that can just run and get into the debugger. Select AppBasicExampleGui and expand it. Open the file BasicExample.cpp. This is an example program that demonstrates the Bullet Physics library by rendering a bunch of cubes arranged as a single block that are falling and smash apart on hitting a surface. Next set a break point that will be triggered when you click in the running application. That is handled in a method within a helper class used by this application. To quickly get there select CommonRigidBodyBase that the struct BasicExample is derived from around line 30. Right click and choose Go to Definition. Now you are in the header CommonRigidBodyBase.h. In the browser view above your source you should see that you are in the CommonRigidBodyBase. To the right you can select members within to examine, drop that selection down and select mouseButtonCallbackwhich will take you to the definition of that function in the header.

Place a breakpoint on the first line within this function. This will trigger when you click a mouse button within the window of the application when launched under the Visual Studio debugger.

To launch the application, select the launch dropdown with the play icon that says “Select Startup Item” in the toolbar.

In the dropdown select AppBasicExampleGui.exe. Now press the launch button. This will cause the project to build our application and necessary dependencies, then launch it with the Visual Studio debugger attached. It will take a few moments while this process starts, then the application will appear.

Move your mouse into the application window, click a button, and the breakpoint will be triggered. This pause execution of your program, bring Visual Studio back to the foreground, and you will be at your breakpoint. You will be able to inspect the application variables, objects, threads, memory, and step through your code interactively using Visual Studio. You can click continue to let the application resume and exit it normally or cease execution within Visual Studio using the stop button.

What you have seen so far is by simply cloning a C++ repo from GitHub you can open the folder with Visual Studio and get an experience that provides IntelliSense, a file view, a logical view based on the build targets, source navigation, build, and debugging with no special configuration or Visual Studio specific project files. If you were to make changes to the source you would get a diff view from the upstream project, make commits, and push them back without leaving Visual Studio. There’s more though. Let’s use this project with Linux.

Step 4 – Add a Linux configuration

So far, you have been using the default x64-Debug configuration for our CMake project. Configurations are how Visual Studio understands what platform target it is going to use for CMake. The default configuration is not represented on disk. When you explicitly add a configuration a file CMakeSettings.json is created that has parameters Visual Studio uses to control how CMake is run, as well as when it is run on a remote target like Linux. To add a new configuration, select the Configuration drop down in the toolbar and select “Manage Configurations…”

The Add Configuration to CMakeSettings dialog will appear.

Here you see Visual Studio has preconfigured options for many of the platforms Visual Studio can be configured to use with CMake. If you want to continue to use the default x64-Debug configuration that should be the first one you add. You want that for this tutorial so can switch back and forth between Windows and Linux configurations. Select x64-Debug and click Select. This creates the CMakeSettings.json file with a configuration for “x64-Debug” and switches Visual Studio to use that configuration instead of the default. This happens very quickly as the provided settings are the same as the default. You will see the configuration drop down no longer says “(default)” as part of the name.

You can use whatever names you like for your configurations by changing the name parameter in the CMakeSettings.json.

Now that you have a configuration specified in the configuration dropdown Manage Configurations option opens the CMakeSettings.json file so you can adjust values there. To add a Linux configuration right click the CMakeSettings.json file in the solution explorer view and select Add Configuration.

This provides the same Add Configuration to CMakeSettings dialog you saw before. This time select Linux-Debug, then save the CMakeSettings.json file. Now in the configuration drop down select Linux-Debug.

Since this is the first time you are connecting to a Linux system the Connect to Remote System dialog will appear.

Provide the connection information to your Linux machine and click Connect. This will add that machine as your default remote machine which is what the CMakeSetttings.json for Linux-Debug is configured to use. It will also pull down the headers from your remote machine so that you get IntelliSense specific to that machine when you use it. Now Visual Studio will send your files to the remote machine, then generate the CMake cache there, and when that is done Visual Studio will be configured for using the same source base with that remote Linux machine. These steps may take some time depending on the speed of your network and power of your remote machine. You will know this is complete when the message “Target info extraction done” appears in the CMake output window.

Step 5 – Set breakpoint, build and run on Linux

Since this is a desktop application you need to provide some additional configuration information to the debug configuration. In the CMake Targets view right click AppBasicExampleGui and choose Debug and Launch settings.

This will open a file launch.vs.json that is in the hidden .vs subfolder. This file is local to your development environment. You can move it into the root of your project if you wish to check it in and save it with your team. In this file a configuration has been added for AppBasicExampleGui. These default settings work in most cases, as this is a desktop application you need to provide some additional information to launch the program in a way you can see it on our Linux machine. You need to know the value of the environment variable DISPLAY on your Linux machine, run this command to get it.

In my case this was :1. In the configuration for AppBasicExampleGui there is a parameter array “pipeArgs”. Within there is a line “$”. This is the command that launches gdb on the remote machine. Visual Studio needs to export the display into this context before that command runs. Do so by modifying that line as follows using the value of your display.

Now in order to launch and debug our application, choose the “Select Startup Item” dropdown in the toolbar and choose AppBasicExampleGui.

Now press that button or hit F5. This will build the application and its dependencies on the remote Linux machine then launch it with the Visual Studio debugger attached. On your remote Linux machine, you should see an application window appear with the same falling bunch of cubes arranged as a single block.

Move your mouse into the application window, click a button, and the breakpoint will be triggered. This pause execution of your program, bring Visual Studio back to the foreground, and you will be at your breakpoint. You should also see a Linux Console Window appear in Visual Studio. This window provides output from the remote Linux machine, and it can also accept input for stdin. It can of course be docked where you prefer to see it and it’s position will be used again in future sessions.

You will be able to inspect the application variables, objects, threads, memory, and step through your code interactively using Visual Studio. This time on a remote Linux machine instead of your local Windows environment. You can click continue to let the application resume and exit it normally or cease execution within Visual Studio using the stop button. All the same things you’d expect if this were running locally.

Look at the Call Stack window and you will see this time the Calls to x11OpenGLWindow since Visual Studio has launched the application on Linux.

What you learned and where to learn more

So now you have seen the same code base, cloned directly from GitHub, build, run, and debugged on Windows with no modifications. Then with some minor configuration settings build, run and debugged on a remote Linux machine as well. If you are doing cross platform development, we hope you find a lot to love here. Visual Studio C and C++ development is not just for Windows anymore.

Further articles

• Original Linux C++ announcement post, this goes into depth on Linux C++ projects that use msbuild to drive remote compilation.

Documentation links

This section will be updated in the future with links to new articles on Cross Platform Development with Visual Studio.

Give us feedback

Use this link to download Visual Studio 2017 with everything you need to try the steps in this tutorial, then try it with your projects.

Your feedback is very important to us. We look forward to hearing from you and seeing the things you make.

Источник