You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The CL tool uses the following environment variables:
11
11
12
-
- CL and \_CL\_, if defined. The CL tool prepends the options and arguments defined in the CL environment variable to the commandline arguments, and appends the options and arguments defined in \_CL\_, before processing.
12
+
- CL and \_CL_, if defined. The CL tool prepends the options and arguments defined in the CL environment variable to the command-line arguments, and appends the options and arguments defined in \_CL_, before processing.
13
13
14
14
- INCLUDE, which must point to the \include subdirectory of your Visual Studio installation.
15
15
16
-
- LIBPATH, which specifies directories to search for metadata files referenced with [#using](../../preprocessor/hash-using-directive-cpp.md). See `#using` for more information on LIBPATH.
16
+
- LIBPATH, which specifies directories to search for metadata files referenced with [#using](../../preprocessor/hash-using-directive-cpp.md). For more information on LIBPATH, see [#using](../../preprocessor/hash-using-directive-cpp.md).
17
17
18
-
You can set the CL or \_CL\_ environment variable using the following syntax:
18
+
You can set the CL or \_CL_ environment variable using the following syntax:
19
19
20
-
> SET CL=[[*option*] ... [*file*] ...][/link *link-opt* ...]
20
+
> SET CL=[[*option*] ... [*file*] ...][/link *link-opt* ...]\
21
21
> SET \_CL\_=[[*option*] ... [*file*] ...][/link *link-opt* ...]
22
22
23
-
For details on the arguments to the CL and \_CL\_ environment variables, see [MSVC Compiler Command-Line Syntax](compiler-command-line-syntax.md).
23
+
For details on the arguments to the CL and \_CL_ environment variables, see [MSVC Compiler Command-Line Syntax](compiler-command-line-syntax.md).
24
24
25
-
You can use these environment variables to define the files and options you use most often and use the command line to define specific files and options for specific purposes. The CL and \_CL\_ environment variables are limited to 1024 characters (the command-line input limit).
25
+
You can use these environment variables to define the files and options you use most often. Then use the command line to give more files and options to CL for specific purposes. The CL and \_CL_ environment variables are limited to 1024 characters (the command-line input limit).
26
26
27
-
You cannot use the /D option to define a symbol that uses an equal sign (=). You can substitute the number sign (#) for an equal sign. In this way, you can use the CL or \_CL\_ environment variables to define preprocessor constants with explicit values—for example, `/DDEBUG#1` to define `DEBUG=1`.
27
+
You can't use the [/D](d-preprocessor-definitions.md) option to define a symbol that uses an equal sign (**=**). Instead, you can use the number sign (**#**) for an equal sign. In this way, you can use the CL or \_CL_ environment variables to define preprocessor constants with explicit values—for example, `/DDEBUG#1` to define `DEBUG=1`.
28
28
29
29
For related information, see [Set Environment Variables](../setting-the-path-and-environment-variables-for-command-line-builds.md).
30
30
31
31
## Examples
32
32
33
-
The following is an example of setting the CL environment variable:
33
+
The following command is an example of setting the CL environment variable:
34
34
35
35
> SET CL=/Zp2 /Ox /I\INCLUDE\MYINCLS \LIB\BINMODE.OBJ
36
36
37
-
When this environment variable is set, if you enter `CL INPUT.C` at the command line, this is the effective command:
37
+
When the CL environment variable is set, if you enter `CL INPUT.C` at the command line, the effective command becomes:
The following example causes a plain CL command to compile the source files FILE1.c and FILE2.c, and then link the object files FILE1.obj, FILE2.obj, and FILE3.obj:
42
42
43
-
> SET CL=FILE1.C FILE2.C
44
-
> SET \_CL\_=FILE3.OBJ
43
+
> SET CL=FILE1.C FILE2.C\
44
+
> SET \_CL_=FILE3.OBJ\
45
45
> CL
46
46
47
-
This has the same effect as the following command line:
47
+
These environment variables make the call to CL have the same effect as the following command line:
Copy file name to clipboardExpand all lines: docs/c-runtime-library/reference/get-osfhandle.md
+8-2Lines changed: 8 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -27,11 +27,16 @@ An existing file descriptor.
27
27
28
28
## Return Value
29
29
30
-
Returns an operating-system file handle if *fd* is valid. Otherwise, the invalid parameter handler is invoked, as described in [Parameter Validation](../../c-runtime-library/parameter-validation.md). If execution is allowed to continue, this function returns **INVALID_HANDLE_VALUE** (-1) and sets **errno** to **EBADF**, indicating an invalid file handle. To avoid a compiler warning when the result is used in routines that expect a Win32 file handle, cast it to a **HANDLE** type.
30
+
Returns an operating-system file handle if *fd* is valid. Otherwise, the invalid parameter handler is invoked, as described in [Parameter Validation](../../c-runtime-library/parameter-validation.md). If execution is allowed to continue, it returns **INVALID_HANDLE_VALUE** (-1). It also sets **errno** to **EBADF**, indicating an invalid file handle. To avoid a warning when the result is used as a Win32 file handle, cast it to a **HANDLE** type.
31
+
32
+
> [!NOTE]
33
+
> When **stdin**, **stdout**, and **stderr** aren't associated with a stream (for example, in a Windows application without a console window), the file descriptor values for these streams are returned from [_fileno](fileno.md) as the special value -2. Similarly, if you use a 0, 1, or 2 as the file descriptor parameter instead of the result of a call to **_fileno**, **_get_osfhandle** also returns the special value -2 when the file descriptor is not associated with a stream, and does not set **errno**. However, this is not a valid file handle value, and subsequent calls that attempt to use it are likely to fail.
34
+
35
+
For more information about **EBADF** and other error codes, see [_doserrno, errno, _sys_errlist, and _sys_nerr](../../c-runtime-library/errno-doserrno-sys-errlist-and-sys-nerr.md).
31
36
32
37
## Remarks
33
38
34
-
To close a file whose operating system (OS) file handle is obtained by **_get_osfhandle**, call [_close](close.md) on the file descriptor *fd*. Do not call **CloseHandle** on the return value of this function. The underlying OS file handle is owned by the *fd* file descriptor, and is closed when [_close](close.md) is called on *fd*. If the file descriptor is owned by a `FILE *` stream, then calling [fclose](fclose-fcloseall.md) on that `FILE *` stream closes both the file descriptor and the underlying OS file handle. In this case, do not call [_close](close.md) on the file descriptor.
39
+
To close a file whose operating system (OS) file handle is obtained by **_get_osfhandle**, call [_close](close.md) on the file descriptor *fd*. Never call **CloseHandle** on the return value of this function. The underlying OS file handle is owned by the *fd* file descriptor, and is closed when [_close](close.md) is called on *fd*. If the file descriptor is owned by a `FILE *` stream, then calling [fclose](fclose-fcloseall.md) on that `FILE *` stream closes both the file descriptor and the underlying OS file handle. In this case, don't call [_close](close.md) on the file descriptor.
35
40
36
41
## Requirements
37
42
@@ -48,3 +53,4 @@ For more compatibility information, see [Compatibility](../../c-runtime-library/
Associates a C run-time file descriptor with an existing operating-system file handle.
13
+
Associates a C run-time file descriptor with an existing operatingsystem file handle.
14
14
15
15
## Syntax
16
16
@@ -24,7 +24,7 @@ int _open_osfhandle (
24
24
### Parameters
25
25
26
26
*osfhandle*<br/>
27
-
Operating-system file handle.
27
+
Operatingsystem file handle.
28
28
29
29
*flags*<br/>
30
30
Types of operations allowed.
@@ -35,7 +35,7 @@ If successful, **_open_osfhandle** returns a C run-time file descriptor. Otherwi
35
35
36
36
## Remarks
37
37
38
-
The **_open_osfhandle** function allocates a C run-time file descriptor and associates it with the operating-system file handle specified by *osfhandle*. To avoid a compiler warning, cast the *osfhandle* argument from **HANDLE** to **intptr_t**. The *flags* argument is an integer expression formed from one or more of the manifest constants defined in \<fcntl.h>. When two or more manifest constants are used to form the *flags* argument, the constants are combined with the bitwise-OR operator ( **|** ).
38
+
The **_open_osfhandle** function allocates a C run-time file descriptor. It associates this file descriptor with the operatingsystem file handle specified by *osfhandle*. To avoid a compiler warning, cast the *osfhandle* argument from **HANDLE** to **intptr_t**. The *flags* argument is an integer expression formed from one or more of the manifest constants defined in \<fcntl.h>. You can use the bitwise-OR operator ( **|** ) to combine two or more manifest constants to form the *flags* argument.
39
39
40
40
These manifest constants are defined in \<fcntl.h>:
41
41
@@ -46,7 +46,7 @@ These manifest constants are defined in \<fcntl.h>:
46
46
|**\_O\_TEXT**| Opens the file in text (translated) mode. |
47
47
|**\_O\_WTEXT**| Opens the file in Unicode (translated UTF-16) mode. |
48
48
49
-
The **_open_osfhandle** call transfers ownership of the Win32 file handle to the file descriptor. To close a file opened by using **_open_osfhandle**, call [\_close](close.md). The underlying OS file handle is also closed by a call to **_close**. Don't call the Win32 function **CloseHandle** on the original handle. If the file descriptor is owned by a **FILE *** stream, then a call to [fclose](fclose-fcloseall.md)on that **FILE *** stream closes both the file descriptor and the underlying handle. In this case, don't call **_close** on the file descriptor or **CloseHandle** on the original handle.
49
+
The **_open_osfhandle** call transfers ownership of the Win32 file handle to the file descriptor. To close a file opened by using **_open_osfhandle**, call [\_close](close.md). The underlying OS file handle is also closed by a call to **_close**. Don't call the Win32 function **CloseHandle** on the original handle. If the file descriptor is owned by a **FILE *** stream, then a call to [fclose](fclose-fcloseall.md) closes both the file descriptor and the underlying handle. In this case, don't call **_close** on the file descriptor or **CloseHandle** on the original handle.
50
50
51
51
## Requirements
52
52
@@ -59,3 +59,4 @@ For more compatibility information, see [Compatibility](../../c-runtime-library/
Copy file name to clipboardExpand all lines: docs/linux/cmake-linux-project.md
+28-12Lines changed: 28 additions & 12 deletions
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,18 @@
1
1
---
2
2
title: "Configure a Linux CMake project in Visual Studio"
3
3
description: "How to configure, edit and compile a Linux CMake project in Visual Studio"
4
-
ms.date: "05/21/2019"
4
+
ms.date: "06/07/2019"
5
5
ms.assetid: f8707b32-f90d-494d-ae0b-1d44425fdc25
6
6
---
7
7
8
8
# Configure a Linux CMake project
9
9
10
+
::: moniker range="vs-2015"
11
+
12
+
Linux support is available in Visual Studio 2017 and later.
13
+
14
+
::: moniker-end
15
+
10
16
When you open a folder that contains a CMake project, Visual Studio uses the metadata that CMake produces to configure IntelliSense and builds automatically. Local configuration and debugging settings are stored in JSON files that can optionally be shared with others who are using Visual Studio.
11
17
12
18
Visual Studio does not modify the CMakeLists.txt files or the original CMake cache, so that others working on the same project can continue to use whatever tools they are already using.
@@ -17,7 +23,7 @@ For general information about CMake support in Visual Studio, see [CMake Tools f
17
23
18
24
First, make sure you have the **Linux development with C++** workload installed, including the CMake component. See [Install the C++ Linux workload in Visual Studio](download-install-and-setup-the-linux-development-workload.md).
19
25
20
-
On the Linux machine, make sure that the following are installed:
26
+
On the Linux system, make sure that the following are installed:
21
27
22
28
- gcc
23
29
- gdb
@@ -26,16 +32,16 @@ On the Linux machine, make sure that the following are installed:
26
32
27
33
::: moniker range="vs-2019"
28
34
29
-
Linux support for CMake projects requires a recent version of CMake to be installed on the target machine. Often, the version offered by a distribution’s default package manager is not recent enough to support all the IDE’s features. Visual Studio 2019 can automatically install a user local copy of CMake on remote Linux machines that don’t have a recent version of CMake installed. If a compatible version of CMake isn’t detected the first time you build your project, you will see an info-bar offering to install CMake.
30
-
31
-
The binaries will be installed to `~/.vs/cmake`. After deploying the binaries, your project will automatically regenerate. Note that if the CMake specified by the `cmakeExecutable` field in `CMakeSettings.json` is invalid (doesn't exist or is an unsupported version) and the prebuilt binaries are present Visual Studio will ignore `cmakeExecutable` and use the prebuilt binaries.
35
+
Linux support for CMake projects requires a recent version of CMake to be installed on the target machine. Often, the version offered by a distribution’s default package manager is not recent enough to support all the features that are required by Visual Studio. Visual Studio 2019 detects whether a recent version of CMake is installed on the Linux system. If none is found, Visual Studio shows an info-bar at the top of the editor pane that offers to install it for you.
32
36
33
37
::: moniker-end
34
38
35
39
::: moniker range="vs-2017"
36
40
37
41
The CMake support in Visual Studio requires the server mode support that was introduced in CMake 3.8. For a Microsoft-provided CMake variant, download the latest prebuilt binaries at [https://github.com/Microsoft/CMake/releases](https://github.com/Microsoft/CMake/releases).
38
42
43
+
The binaries will be installed to `~/.vs/cmake`. After deploying the binaries, your project will automatically regenerate. Note that if the CMake specified by the `cmakeExecutable` field in `CMakeSettings.json` is invalid (doesn't exist or is an unsupported version) and the prebuilt binaries are present Visual Studio will ignore `cmakeExecutable` and use the prebuilt binaries.
As soon as you open the folder, Visual Studio parses the CMakeLists.txt file and specifies a Windows target of **x86-Debug**. To target Linux, change the project settings to **Linux-Debug** or **Linux-Release**.
72
+
As soon as you open the folder, Visual Studio parses the CMakeLists.txt file and specifies a Windows target of **x86-Debug**. To target a remote Linux system, change the project settings to **Linux-Debug** or **Linux-Release**.
73
+
74
+
::: moniker range="vs-2019"
75
+
76
+
To target Windows Subsystem for Linux, choose **WSL-Debug** or **WSL-Release** if using GCC, or the Clang variants if using the Clang/LLVM toolset.
77
+
78
+
**Visual Studio 2019 version 16.1** When targeting WSL, no copying or sources or headers is necessary because the compiler on Linux has direct access to the Windows file system where your source files are located, and Visual Studio likewise can access the Linux header files directly.
79
+
80
+
::: moniker-end
81
+
82
+
For remote targets, Visual Studio by default chooses the first remote system in the list under **Tools** > **Options** > **Cross Platform** > **Connection Manager**. If no remote connections are found, you are prompted to create one. For more information, see [Connect to your remote Linux computer](connect-to-your-remote-linux-computer.md).
67
83
68
-
By default, Visual Studio chooses the first remote system in the list under **Tools** > **Options** > **Cross Platform** > **Connection Manager**. If no remote connections are found, you are prompted to create one. For more information, see [Connect to your remote Linux computer](connect-to-your-remote-linux-computer.md).
84
+
If you specify a remote Linux target, your source is copied to the remote system.
69
85
70
-
After you specify a Linux target, your source is copied to your Linux machine. Then, CMake is run on the Linux machine to generate the CMake cache for your project.
86
+
After you select a target, CMake runs automatically on the Linux system to generate the CMake cache for your project.
71
87
72
88
![Generate CMake cache on Linux](media/cmake-linux-1.png"Generate the CMake cache on Linux")
73
89
74
-
To provide IntelliSense support for remote headers, Visual Studio automatically copies them from the Linux machine to a directory on your local Windows machine. For more information, see [IntelliSense for remote headers](configure-a-linux-project.md#remote_intellisense).
90
+
To provide IntelliSense support for headers on remote Linux systems, Visual Studio automatically copies them from the Linux machine to a directory on your local Windows machine. For more information, see [IntelliSense for remote headers](configure-a-linux-project.md#remote_intellisense).
75
91
76
92
## Debug the project
77
93
78
-
To debug your code on the remote system, set a breakpoint, select the CMake target as the startup item in the toolbar menu next to the project setting, and choose **⏵ Start** on the toolbar, or press F5.
94
+
To debug your code on the specified debug target system, set a breakpoint, select the CMake target as the startup item in the toolbar menu next to the project setting, and choose **⏵ Start** on the toolbar, or press F5.
79
95
80
96
To customize your program’s command line arguments, right-click on the executable in **Solution Explorer** and select **Debug and Launch Settings**. This opens or creates a launch.vs.json configuration file that contains information about your program. To specify additional arguments, add them in the `args` JSON array. For more information, see [Open Folder projects for C++](../build/open-folder-projects-cpp.md) and [Configure CMake debugging sessions](../build/configure-cmake-debugging-sessions.md).
81
97
@@ -87,7 +103,7 @@ A CMakeSettings.json file in a CMake Linux project can specify all the propertie
87
103
88
104
To change the default CMake settings in Visual Studio 2019, from the main toolbar, open the **Configuration** drop down and choose **Manage Configurations**.
This brings up the **CMake Settings Editor** which you can use to edit the `CMakeSettings.json` file in your root project folder. You can also open the file directly by clicking the **Edit JSON** button in the editor. For more information, see [Customize CMake Settings](../build/customize-cmake-settings.md).
93
109
@@ -153,7 +169,7 @@ You can use these optional settings for more control:
153
169
}
154
170
```
155
171
156
-
These options allow you to run commands on the remote system before and after building, and before CMake generation. The values can be any command that is valid on the remote system. The output is piped back to Visual Studio.
172
+
These options allow you to run commands on the Linux system before and after building, and before CMake generation. The values can be any command that is valid on the remote system. The output is piped back to Visual Studio.
0 commit comments