I am new to VS Code and, coming from VS, I'm struggling to understand how to set up different configurations using the Microsoft C/C++ extension. I followed the documentation, but it seems to me that the content in c_cpp_properties.json is only affecting Intellisense and has no correlation to the actual build, which is set up in tasks.json. The configurations I enter are showing up and selectable at the lower right of the editor window: Intellisense reflects this by apparent knowledge about include folders, etc. However, when I build or run, they don't have any effect, I get errors such as "No such file or directory" for included files. As far as I see it, this is not mentioned in the documentation at all.
How can I make use of the actual selected configuration for the build system?
Related
I am currently using Visual Studio 2013 (Update 4) for building Qt5.4.0 projects. I use the express version so I don't use the VS plugin. My .vcxproj files a generated from .pro files using build scripts and qmake.
When debugging my projects I sometimes try to step into Qt library code. To do this I added the path to the Qt source codes to the solution properties->Debug Source Files setting like described in a former post (VS2013 debugger can not find Qt sources).
Because I have many different projects and it would be a pain to update all of them in case of a Qt update I used a system environment variable "QTSRC" pointing to that path and added the following line to the solution:
$(QTSRC)
This worked like charm some time ago (with an older update of VS and a former Qt version 5.x).
But unfortunately it does not work anymore. It seems that VS now totally ignores the system environment variable (it also does not show any errors when I check the "check entries" button in the dialog).
Does anybody know what changed here lately and what must be done to fix this? It would be very annoying to add the path hardcoded to every project (which still works) and have to do this over and over again after Qt updates.
I'd look at the Property Pages which will allow you to set user defined values that you can share across different projects:
http://msdn.microsoft.com/en-us/library/675f1588.aspx
I use them to set global include paths, but it looks like you can set almost anything there. Set things in the .User pages if you want them used for all your projects but not included in the solution or project file itself.
A good, short, guide is here:
http://www.curlybrace.com/words/2012/12/17/setting-global-c-include-paths-in-visual-studio-2012-and-2011-and-2010/
I am trying to import an existing c++ application's source into visual studio to take advantage of some specific MS tools. However, after searching online and playing with visual studio, I cannot seem to find an easy way to import existing c++ source code into visual studio and keep it structurally intact.
The import capacity I did find flattens out the directories and puts them all into one project. Am I missing something?
(This is all unmanaged C++, and contains specific builds for win/unix)
With no project/solution loaded, in Visual Studio 2005 I see this menu item:
File > New Project From Existing Code...
After following the wizard, my problem is solved!
Switching the "Show All Files" button shows the complete hierarchy with all directories and files within.
If the New Project From Existing Code... option isn't available, you'll need to add it in Tools > Customize...
I am not aware of any general solution under the constraints given - specifically having to create many projects from a source tree.
The best option I see is actually creating the project files by some script.
Creating a single project manually (create empty project, then add the files),
Configure it as close as possible as desired (i.e. with precompiled headers, build configurations, etc.)
Use the .vcproj created as skeleton for the project files to be created
A very simple method would file list, project name etc. with "strange tokens", and fill them in with your generator. If you want to be the good guy, you can of course use some XML handling library.
Our experience: We actually don't store the .vcproj and .sln in the repository (git) anymore, but a python script that re-genrates them from the source tree, together with VS 2008 "property sheet templates" (or whatever they are called). This helps a lot making general adjustments.
The project generation script contains information about all the projects specialties (e.g. do they use MFC/ATL, will it create DLL or an EXE, files to exclude).
In addition, this script also contains dependencies, which feeds the actual build script.
This works quite well, the problems are minor: python requried in build systems, not forgetting to re-gen the project files, me having to learn some python to make adjustments to some projects.
#Michael Burr "How complex are the python scripts and whatever supporting 'templates' you might need?"
I honestly can't tell, since I gave the task to another dev (who picked python). The original task was to provide a build script, as the VS2008 solution build was not good enough for our needs, and the old batch file didn't support parallelization. .vcproj generation was added later. As I understand his script generates the .vcproj and .sln files from scratch, but pulls in all the settings from separate property sheets.
Pros:
Adding new configurations on the fly. Some of the projects already had six configurations, and planning for unicode support meant considering doubling them for a while. Some awkward tools still build as MBCS, so some libs do have 8 configs now. Configuring that from hand is a pain, now it just doesn't bother me anymore.
Global changes, e.g. moving around relative project paths, the folder for temp files and for final binaries until we found a solution we were happy with
Build Stability. Merging VC6 project files was a notable source of errors for various reasons, and VC9 project files didn't look better. Now things seem isolated better: compile/link settings in the property sheets, file handling in the script. Also, the script mostly lists variations from our default, ending up easier to read than a project file.
Generally: I don't see a big benefit when your projects are already set up, they are rather stable, and you don't have real issues. However, when moving into the unknown (for us: mostly VC6 -> VC9 and Unicode builds), the flexibility reduced the risk of experiments greatly.
Create a new empty solution and add your source code to it.
For example,
File>New>Project...
Visual C++>Win32>Win32 Console Application
Application Settings>
- Uncheck "Precompiled Header"
- Check "Empty Project"
Project is then created. To add existing code:
Project>Add Existing Item...>
- Select file(s) to add
Recompile, done!
In the "Solution Explorer" you can click on the "Show All Files" button to have Visual Studio display the files as they exist on the file system (directories and all).
In my opinion this is an imperfect workaround, but I believe it's the best available. I'm unaware of a plug-in, macro or other tool that'll import a directory into an actual project with folders that mirror the file system's.
I know this question is already marked correct, but I was able to import existing code into a project with Visual Studio 2008 by doing "File" -> "New Project from existing code". The directory structure of my code was retained.
You can always switch view from project menu
For eg. Project->Show All Files
The above will display the files in unformated raw file system order
Not sure of older versions but it works on VS 2010
I understand you, I have the same problem: many .cpp and .h files organized in many folders and subfolders with include paths written for this folder structure. The only way you can do to import this folder structure together with the source files is to use "Show All Files" and then right-click on folders and select "Import in Project". This works for me when I am using C-Sharp projects. But it does not work for my C++ Projects. I am still searching for a solution...
I'm using Eclipse with C++ code via linked resources on Linux. The code analysis index seems to be corrupted (Goto definition lands the cursor close to, but not on, the definition) Refreshing resources doesn't fix it, neither does restarting Eclipse.
Is there a way to flush the index and rebuild it?
Right-click on your project, go under the Index submenu, and choose either "Rebuild," "Update with modified files," or "Freshen all files."
I don't know the difference between those three options, but one of "Update with modified files" or "Freshen all files" usually fixes it for me.
Also, I'm sure you've already done this, but make sure that you're running the latest version of the Eclipse CDT. Current versions seem to have much more reliable indexing than previous versions.
From http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg10390.html, the differences between "Rebuild," "Update with modified files," or "Freshen all files":
Rebuild: Works for entire projects, only. Clears the index and indexes
the files from scratch. When cancelled it leaves you with an empty or
partial index.
Update with Modified Files: Works on a resource
selection. Checks on individual files whether the timestamp or the
scanner-config has been changed and updates the index for the changed
files.
Freshen All Files: Works on a resource selection. Updates the
selected files in the index. The index is not cleared, it is safe to
cancel the operation.
Go to your project properties -> C++ general -> Indexer.
Do this with 'project specific settings',
(or on 'Configure Workspace Settings...').
Deselect 'Enable Indexer' hit Apply.
Select 'Enable Indexer' hit Apply.
This should completely wipe out and rebuild the index.
Neither of the above worked for me (Eclipse Indigo), index still broken and refusing to rebuild properly. Until applied this one:
http://slsam2.blogspot.com/2012/02/eclipse-cdt-index-not-working.html
The crucial bit of the linked post is this:
Eclipse no longer treats your project as a C++ project. Choose menu File/New/Convert to a C/C++ project. It takes a while to index the source code.
I still wonder how Eclipse can uncontrollably shoot itself in the foot like that. I suspect that installing additional packages can trigger it. Perhaps JavaScript support in my case.
delete only the .pdom file under .metadata.plugins\org.eclipse.cdt.core helps, I got the indexer screwed after upgrading Neon.2 to Neon.3 and this seems to solve the problem.
(this comment already exists above but am not allowed to confirm it up there).
I found that I had the global indexer set to 'Use the build configuration specified in the project's indexer settings',
and the project's indexer set to NOT use project specific indexer settings.
Regardless, it was using the same fixed configuration for the indexer regardless of which configuration I had selected.
The fix:
Window-Preferences, C/C++, Indexer. Select "Use active build configuration" in section "Build configuration for the indexer".
Happy days.
Did you try adding -clean to the command line for the eclipse executable?
Eclipse no longer treats your project as a C++ project. Choose menu File/New/Convert to a C/C++ project. It takes a while to index the source code. worked for me
I started with trying Josh Kelleys and mmmmms answers without any luck, but I finally fixed it by checking my include paths.
One way to see them are in the Project Explorer, expand project and there should be an entry "Includes". Inside that, check for a small yellow warning triangle on each include path. If that triangle is present eclipse most likely doesn't recognize the path.
The include paths are edited through right-clicking on "Your project" in the Project explorer, then choose "Properties" --> C/C++ General --> Paths and Symbols --> Includes.
I see three language options, Assembly, Gnu C, Gnu C++. Choose the correct one before starting to add paths (likely Gnu C++). After adding all the paths, -->Apply --> Ok and rebuild index if you're asked to.
My erroneous workspace paths looked like MyProject/MyProject/folder when it was supposed to be MyProject/folder.
For me the "Problems"-view is always slow to update, even after rebuilding index. To be sure that the error is still there, double-click the problems entry so that eclipse opens/reloads the file in question. This often seems necessary for me to update the "Problems" view.
I don't really know if it was eclipse or my scm that messed it up. Anyway, hope it helps someone!
I use Luna and builds with an external makefile.
In a single solution, if I have the same source file present in multiple projects (with different project settings, e.g. different #defines), Intellisense and all the features depending on it seems to arbitrary pick one of the project settings when I edit the source file.
How do I get Intellisense to switch which project settings it uses for that file ?
If that is not possible, it would be at least useful to know which project Intellisense picks ?
I have exactly the same problem using VS2005. I read a while back that Microsoft found this to be 'intended functionality' and would not sort this out.
It seems that intellisense uses the first loaded project of the solution to apply the #defines for.
We just got a new developer and I'm trying to set him up with Dev Studio 2005 (The version we all use at this office), and we're running into a weird problem that I've never seen before.
I have some code that works perfectly on my system, and he can't seem to get it compiled. We've tracked the issue down to his copy of dev studio ignoring the preprocessor directives.
For example, in the project properties under C/C++|Preprocessor|Preprocessor Directives, I add DEFINE_ME. Which should translate to a /D"DEFINE_ME" for the compiler. And it does in my development environment, but it doesn't on his.
I verified that when he checks out the code from the source repository, that he has the same version of the code I do. And if I look in his Project Properties, all of the directives are there. For some reason they're just not getting passed down to the compiler.
Any Ideas?
I recently ran into the same symptom with VS2005. Ultimately I was able to resolve it by explicitly adding my preprocessor defines via the Command Line - Additional options dialog:
Configuration Properties -> C/C++ -> Command Line
When I added '/DPROPERTY' there it was recognized at compile time, whereas adding it under 'Preprocessor -> Preprocessor Definitions' did nothing. Oddly the Command Line dialog did show that Visual Studio was adding the property to the command line, albeit in the form '/D "PROPERTY"'.
Unfortunately schedule pressure being what it is I have not been able to dig into the issue deep enough to figure out what the underlying issue was/is, nor why it seems to work out of the box for some of our projects but not others. Nonetheless the workaround above is worth a shot if you're having this symptom.
Also, credit where credit is due: the idea came from this thread.
Make sure that the project configuration which is being built in the selected solution configuration is the same as the one you're configuring the properties for, and/or that you're configuring the properties for all project configurations. A common problem with new VS installations is that the current active solution configuration is system-specific, and may default to something not matching yours (eg: Release vs Debug).
You can see the project config in the build output, and/or check it in the Configuration Manager.