When using the "Default" intellisense engine, some of the symbols in my C++ project cannot be resolved. It turns out that it's because they are in headers where they are guarded by an #ifdef that depends on a macro passed to gcc with the -D flag by the makefile. How can I tell the intellisense engine about these defines so that it is able to compile those parts of the header?
Project makefile defines are set in .vscode/c_cpp_properties.json.
"configurations": [
{
...
"defines":[
"MYSYMBOL",
"MYVALUE=1"
]
}
], ...
Here are some methods to open c_cpp_properties.json:
Find a green squiggle on something like an include statement that Intellisense can't resolve. Hover around and click the lightbulb that appears (which is tiny and a bit of a game to click). It will open the project config file in the editor.
Same as above, but put cursor on the green squiggle line and press Ctrl+..
Use the command pallet: ctrl+shift+P, then select C/C++: Edit configurations (JSON).
If the file already exists in your .vscode folder, open it with File->Open.
Although vscode will reprocess the settings after c_cpp_properties.json is modified, I found a restart is sometimes required when changing values.
There is basic and incomplete information here: https://code.visualstudio.com/docs/languages/cpp
This is a good link about the c_cpp_properties.json file itself: https://code.visualstudio.com/docs/cpp/c-cpp-properties-schema-reference
The other answers so far have two issues that don't seem trivial to fix:
There might be times where different source files need different compiler flags.
It could be painfully tedious to manually figure out what compiler flags are necessary and manually add them.
Luckily, VS Code's C/C++ extension supports a compile_commands.json database. This stores information specific to every individual source file including the defines, include directories, and other compiler command line flags. I just posted a more detailed description of how to generate one and get VS Code to use it over here: https://stackoverflow.com/a/59618515/12663912
This capability has now been added: https://github.com/Microsoft/vscode-cpptools/issues/304
you can set "defines" in your c_cpp_properties.json file
After following the advice in this thread I still couldn't get vscode to recognise the macros I'd defined in c_cpp_properties.json.
Turns out, if you're using the CMake extension for vscode and have the "all" target selected then any macros you've defined in your CMakeLists won't be recognised, nor will any in the c_cpp_properties.json. It was as straightforward as selecting a target to build from the status bar and intellisense was able to pick up any macros defined for that target. No need for the c_cpp_properties.json.
Related
I am a C# developer, and spoiled rotten when it comes to references and dependencies. I am working on a small project now in Visual C++ (Visuial Studio 2017), where I want to use the libtomcrypt and libtommath libraries. I've created a small project and added the 2 projects to my solution:
I have also added my includes:
And I added the dependencies:
However, I still can't build:
Error C1083 Cannot open include file: 'tomcrypt.h': No such file or directory
I am not sure what else I need to do to get the references working and the code to compile. Any pointers is appreciated!
The error message indicates that the compiler can't find the file tomcrypt.h while compiling one of your source files. From the message I would guess that you have a line like the following in your source file:
#include <tomcrypt.h>
(...or perhaps with quotes instead of brackets.) From your screenshot I can see that you've added "...\repos\libtomcrypt-develop\src\headers" to your include path. Is the file tomcrypt.h found directly in that folder, or is it perhaps in a subfolder instead?
Your #include directive will basically append whatever path you give it to each entry in your include path when looking for the file, so if there are subfolders in between, you'll have to expand your #include directive to include those folders.
If this doesn't solve your problem, perhaps try posting the actual full path of where this header file exists on your filesystem, as well as your complete include path value! (The full compiler command from the build log would be useful, as well as the complete error message(s) related to this source file.)
Edit:
The original poster posted a separate answer indicating that the actual problem was that the Visual Studio Project Properties were set correctly, but that he was accidentally trying to build a different Configuration. :(
I was building the project under x86. Once I changed it to x64, it built just fine.
When using the "Default" intellisense engine, some of the symbols in my C++ project cannot be resolved. It turns out that it's because they are in headers where they are guarded by an #ifdef that depends on a macro passed to gcc with the -D flag by the makefile. How can I tell the intellisense engine about these defines so that it is able to compile those parts of the header?
Project makefile defines are set in .vscode/c_cpp_properties.json.
"configurations": [
{
...
"defines":[
"MYSYMBOL",
"MYVALUE=1"
]
}
], ...
Here are some methods to open c_cpp_properties.json:
Find a green squiggle on something like an include statement that Intellisense can't resolve. Hover around and click the lightbulb that appears (which is tiny and a bit of a game to click). It will open the project config file in the editor.
Same as above, but put cursor on the green squiggle line and press Ctrl+..
Use the command pallet: ctrl+shift+P, then select C/C++: Edit configurations (JSON).
If the file already exists in your .vscode folder, open it with File->Open.
Although vscode will reprocess the settings after c_cpp_properties.json is modified, I found a restart is sometimes required when changing values.
There is basic and incomplete information here: https://code.visualstudio.com/docs/languages/cpp
This is a good link about the c_cpp_properties.json file itself: https://code.visualstudio.com/docs/cpp/c-cpp-properties-schema-reference
The other answers so far have two issues that don't seem trivial to fix:
There might be times where different source files need different compiler flags.
It could be painfully tedious to manually figure out what compiler flags are necessary and manually add them.
Luckily, VS Code's C/C++ extension supports a compile_commands.json database. This stores information specific to every individual source file including the defines, include directories, and other compiler command line flags. I just posted a more detailed description of how to generate one and get VS Code to use it over here: https://stackoverflow.com/a/59618515/12663912
This capability has now been added: https://github.com/Microsoft/vscode-cpptools/issues/304
you can set "defines" in your c_cpp_properties.json file
After following the advice in this thread I still couldn't get vscode to recognise the macros I'd defined in c_cpp_properties.json.
Turns out, if you're using the CMake extension for vscode and have the "all" target selected then any macros you've defined in your CMakeLists won't be recognised, nor will any in the c_cpp_properties.json. It was as straightforward as selecting a target to build from the status bar and intellisense was able to pick up any macros defined for that target. No need for the c_cpp_properties.json.
I have a C++ project built of several shared libraries. Each library source code is placed under its subtree of directories. The main CMakeList file contains a list of add_subdirectory(<dirname>) directives. CMakeList files in every subdirectory contain definitions like the following:
set (SOURCE_FILES
util/src/Connector.cpp
pub/util/Connector.h
)
add_library(channels SHARED $( SOURCE_FILES))
SET_TARGET_PROPERTIES(channels PROPERTIES LINKER_LANGUAGE CXX)
where channels is the subdirectory name.
Although the search path for include files is set correctly and compilation works, KDevelop does not see the Connector.h header file and, therefore, its parsing and code/class browser do not work.
I know that .kdev_include_paths file in every directory might solve the problem. Unfortunately, this approach may not be used due to some additional constraints in our development environment.
Is there any other way to solve this issue?
I use Intel C/C++ compiler on RHEL 7.1 with KDevelop 5.0.4 running from AppImage.
I found and solved a problem which presented similarly - header files not seen and code/class browser failing. The cause turned out to be an error in my code. For the benefit of others who may write a similar bug and arrive at this page, here is what I did wrong:
I had a header only class in a file 'myClass.hpp' and an empty implementation 'myClass.cpp'. My CmakeLists.txt cited the implementation, but my implementation did not contain #include "myClass.hpp". The effect in Kdevelop-5.1.0 was that the header file was not parsed as part of the program - hence its includes were not read, and much of the code failed semantic analysis.
On KDevelop 5 this solved my issue:
Go to menu "Project" -> "Open Configuration..."
In the window which now opens, go to "Cppcheck" on it's left side and then to "Include Directories" on it's right side
check the "Use 'system' include dirs" option:
Try adding
include_directories(${SOURCE_FILES})
It appears I experienced the same problem.
Symptoms:
-- Kdevelop 5.1.2 could not find some #includes; they were underlined in source files.
-- There was no problem building the project
Cause:
-- Both symbolic links and the original *.h files were in the paths specified in
include_directories( ) in CMakeLists.txt. Symbolic link removal fixed the problem.
Kdevelop is probably right to be confused about multiple *.h files with the same name.
Maybe some future Kdevelop release will be able to recognize that it is dealing with only one target.
I noticed this little sign on a project source file and didn't know what it meant.
It means the file has been configured to be ignored (not compiled) in the project.
The specific option is called 'Exclude From Build' in the General property.
In addition to Steve's answer, I would add:
Your project/solution may have multilple configurations (Debug/Release, Win32/x64, and other custom configurations like "HighPerformance", "ForMobile", "ManagedDLL"), and you may like not to have set of source files get compiled. For, this you may put them into "Excludes".
To put into exclusion, just select the source file (.CPP, .C), open property page for it, and set "Excluded from Build" to Yes. To make it part of build process (i.e. let it compile), set this property to No.
Header Files need not to be put into exclusions, as they wont be compiled by compiler, it is just for programmer's view. Headers are only compiled when some source file do include them.
From this thread
http://www.codeguru.com/forum/showthread.php?p=1863547
It seems this cannot be done with:
#pragma comment(linker, "/out:mycool.exe")
Is there some simple way this can be done without having to use project settings, make files etc?
Added:
Why do I want to do this.
Well this gets into another subject which is probably my next question - working with the IDE.
I have to provide many examples in one project. They are simple single files that demonstrate different ways of doing things and each one should really be a different executable EXample1.exe, Example2.exe.
I only want to paste the source code or hand someone a SINGLE file with everything needed to make the example executable (on a web forum for example. I do not want to attach a 3.6MB project folder just to get a different executable name!
Compiling transcends source code. Source code only exists, and something has to take it and make something of it. Anything you do in source code is really just going to be a directive to the compiler. You might as well use project settings. This stuff isn't standard, because the standard only covers behavior and definitions of source code, not compilers.
g++ takes the output file as a parameter: g++ -o myexe.exe main.cpp. What should it do if it comes across a "output should be this!" directive in the source code?
Same with cl (Visual Studio), it passes the output setting into the command line.
Not to say it's impossible, but I doubt it's worth it to try and come up with a way to do it, let alone make it standard.
To use the linker pragma comment, the output file must NOT be specified in the linker section of the project properties:
project -> properties -> Linker -> General -> Output File
Delete the entry: $(OutDir)\$(ProjectName).exe
then the prama statement will work:
pragma comment(linker, "/out:mycool.exe")
Thanks to JC for the walkthrough
Specifying a complete path is not possible
http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/11a06ecd-dcca-4d81-8626-ba0c5a1835c1/
but the work around is:
What I do is have a header file loacated somewhere near the library file, this header will include the pragma line.
pragma comment(lib, FILE "../libs/mylibary.lib")
if FILE is "C:\Project\SharedLibs\Xvid\latest.h"
then the pragma will include
"C:\Project\SharedLibs\Xvid\libs/mylibary.lib" once it has normalized the uri to remove the ..'s
this will always cause the pragma to include the library with an absolute path created from the path of the accompanying header.
I use this system to include a single header in a project and regardless of the relative paths between the lib and project the lib will always be included cleanly.
Added:
The full path can be specified as long as it is 8.3 format. This can present problems for a path like:
C:\Program Files\Abyss Web Server\htdocs\
Program files is commonly Progra~1
but a folder name with a space is more tricky. In this case it becomes AbyssW~1
The \ must be escaped resulting in \ producing a working pragma of:
#pragma comment(linker, "/out:C:\\Progra~1\\AbyssW~1\\htdocs\\MyApp.exe")
as kibibu showed:
#pragma comment(linker, "/out:\"C:\\Program Files\\Abyss Web Server\\htdocs\\MyApp.exe\"")
also works
If you don't want to stray too far from a stock Visual C++ installation, you should consider using NMake. It can integrate with the IDE using project files, but it can also simply be run from the command-line very easily. It's also far more lightweight than project files for generating an arbitrary number of simple and similar executables.