Visual Studio 2019 always rebuilds everything after I hit the "build" button - c++

I'm new to Visual Studio. Now I'm using Visual Studio 2019 to develop Clang&LLVM. I found that every time I right-click the clang executable in the Solution Explorer and choose "Build" or "Debug->Start new instance", VS starts to re-build everything from scratch, although I haven't changed any source file. Since LLVM is a giant project, this recompilation takes too long.
Is there any solution to make VS smarter to only recompile necessary files (files got changes and their dependencies)?

This could happen if there is a file with "copy always" ("copy to output directory" option)
Fix: Change it to "copy if newer"
You could find these easily by checking the (.vcxproj) project file in a text editor. (search for <CopyToOutputDirectory>, possible values: Never, Always, PreserveNewest. See msbuild-docs)

In my case this problem occur in one specific situation, when project is compile with flag /MP and have "precompiled header".
In above case while compiling your app the file "Microsoft.Build.CPPTasks.CL.read.1.tlog" is created and unfortunately contains paths to temporary files e.g
"\?\C:_Sources\MyApp\OBJ\DEBUG\X64\MyApp\stdafxD-8811C005.PCH.TMP
\?\C:_Sources\MyApp\OBJ\DEBUG\X64\MyApp\PCH-92DA10DF.OBJ.TMP"
When you run compilation again every entries from the file is checked for any changes, since we have entry points to not existing file, the compiler have to compile it again, we can see the "missing" file is a precompiled header, so the entire application must be recompiled
For now I found 3 solutions for this problem:
Do not use flag /MP
Use other build system like ninja, fastbuild, etc.
Write simple app to remove temporary entries from all *.tlog files
and run it before every build
Sample code in c# for solution 3.
static void Main(string[] args)
{
string sobjPath = #"C:\_Sources\MyApp\Obj";
string[] allfiles = Directory.GetFiles(sobjPath, "*.tlog", SearchOption.AllDirectories);
foreach(string filePath in allfiles)
{
List<string> lines = File.ReadAllLines(filePath).ToList();
var linesCount = lines.Count;
lines.RemoveAll(x => x.StartsWith(#"\\?") && x.EndsWith(#".TMP"));
if(linesCount != lines.Count)
{
File.WriteAllLines(filePath, lines);
}
}
}

Source of recompilation can be found in output if diagnostic is set to Tools->Options->Projects and Solutions->Build and Run->MSBuild project build output verbosity = Diagnostic.
In my case it was because they were first builds after installation of new computer. I checked out files from svn but later I changed computer date and time because it was incorrect. After change all previously checked files has date in future so recompilation occurred. To solve issue I deleted all sources and checked out again from svn.

Related

How to properly delete projects in PlatformIO?

I use PlatformIO with Visual Studio Code on Windows 10.
Now whenever I:
create a Project with a name X
close Visual Studio Code
delete the Project folder X
open Visual Studio Code
create a new Project with the same name X
I get an empty project with a main.cpp file as expected, but the IDE shows an error for the line:
#include <Arduino.h>
The Error says: "Include Error recognised. Update your includePath." (Translated)
However, if I try to build, it compiles just fine. Even uploading and running works.
This include error appears not only with Arduino.h but with all includes, even if the file is in the exact same location. And it appears in other files than just main.cpp as well.
Can you tell me why this happens? How can I reuse the project names of deleted projects? Or If I should not delete projects like this (delete the project folder), how else would I delete a project?
I tried this with multiple project names and different boards, always with the same result.
Things I tried so far:
I found a Folder .cache in the PIO directory. But unfortunately renaming it (after step 3) did not help: after restarting PIO it recreated the folder as expected but the error message is still here.
In the same location there is a file homestate.json that among other things contains the path to recently opened projects. I removed those entries without luck.
I am just starting out with VSCoode and PlatformIO so i can't tell you why all of what you are seeing is happening is happening.
I use VSCode v1.63.0 on Windows 10.
If you want to delete the old project name, reuse it or not, you can bring up the Command Palette under the View menu (Shift-Control-P for me) and search for Workspace: Remove Folder from Workspace...., it will only be listed if you have projects in the workspace. A list of projects will be displayed, selected which one to delete and click on it. There will not be a confirmation prompt.

New to Xcode can't open files in c++?

I've been using windows in a class I've been taking but I am trying to run a basic code to figure out how to open/close/input/output from files on Xcode and the code I usually use on visual studios isn't working any idea why? thanks!
#include <string>
#include <iostream>
#include <fstream>
using namespace std;
int main()
{
ifstream fin;
ofstream fout;
string input;
fin.open("inputFile.txt");
if(fin.fail())
cout << "File failed to open." << endl;
fin >> input;
fout.open("outputFile.txt");
fout << input;
}
Put your .txt files in the same directory where your main.cpp file is (or anywhere you like).
In Xcode go to Product > Scheme > Edit Scheme > Run (on the left) > Options (middle top)
Down under Options for "Working Directory" check “Use custom working directory” and set it to the directory where you .txt files are located.
To work with the files, you will have to specify just file names, e.g. in_file.open("inputFile.txt"); no path is necessary.
Here's a completely different approach: Have Xcode copy the input file for you.
Select your project in Xcode
Select Build Phases
Click the '+' button to create a new Build Phase
Select New Copy Files Build Phase
Select Products Directory
Click the '+' button to add your file
Click Add Other
Select your input file and click Open
Check the Copy items… checkbox and click Finish
Now every time you build your project, the input file will be copied to the same folder as the executable no matter where it is built. Of course, to see the output file, you'll still need to find the executable in Finder.
The answers don't really explain the problem so I thought I'd do that.
When you pass a relative path like "inputFile.txt" to file APIs, it's treated as relative to the working directory when the program is executed. This is the same as the 'working directory' when you use cmd.exe or Terminal.app or command lines in general. The Unix command pwd ("print working directory") displays the current working directory. On Windows running the command cd with no arguments performs the same function. (On Unix running cd with no arguments will change the working directory to the user's home directory.)
When you run a program from the command line, the command line shell sets the program's working directory. When you run a program from within an IDE, the IDE sets the working directory. Since, unlike on a command line, there's no obvious answer for what the IDE should set as the working directory, Visual Studio and Xcode set the working directory to different locations by default: Visual Studio sets the working directory to $(ProjectDir), the directory containing the Visual Studio project file; Xcode sets the working directory to the build products directory, i.e. the location the executable was written to.
Some possible solutions to your problem are:
Do not use a relative path, and therefore don't depend on the working directory. This isn't much help in making the program more portable, because the absolute paths will also differ between platforms, and so you will still have to 'configure' the program for each platform. In fact using an absolute path is worse, because it means your source code must differ, whereas it would be better to keep that difference confined to each platform's build configuration.
Configure the IDE to use your desired working directory. Visual Studio can be configured by right clicking the project, selecting Configuration Properties > Debugging > Working Directory, and setting the working directory to the desired path (potentially using Visual Studio build variables).
nepete's answer describes how to configure the working directly set by Xcode.
Configure the IDE's build process to copy your data files to an appropriate location. In Visual Studio you would do this in a C++ project by configuring the project's Properties > Configuration Properties > Build Events.
SSteve's answer covers how to configure additional build steps in Xcode.
I'm guessing you have inputFile.txt in the folder that contains your source code. That's not going to work. You need to put it in the folder that contains the generated executable. To find that folder, right-click on your app under Products and select Show In Finder.
This image shows what it looks like for a command line program. It also shows the Finder window that was opened. As you can see, it is a different folder than the one containing the source code.
As suggested by nepete, edit the scheme, but use $PROJECT_DIR as the custom working directory. Helps with moving the project around, or working in two different environments (e.g., home and office).
BTW. $PROJECT_DIR is one of the Xcode Environment Variables, and also helps with passing file names as command line arguments to programs (settable under "Arguments" in the scheme).
I've struggled with the same problem today. I wanted to add C code to my Swift project and my file pointer was always NULL.
Unfortunately, in XCode 9 for iOS app, I couldn't change the working directory. Changing Build phases didn't help me either. After 4+ hours of trial and error, that's what I've come up with finally and it works:
when copying files to XCode, I've chosen "Create groups", but I needed to choose "Create folder references":
I created a new objective-c file (.m) and copied all my C code there.
I left untouched .h files (XCode generated bridging header and my own .h file with public functions declaration). Now my project structure looked like this:
In my dict.m file in place of previous plain c fopen part:
FILE *dic = fopen("dictionary.txt", "r");
I added obj-C code:
NSString *filePath = [[NSBundle mainBundle] pathForResource:#"dictionary" ofType:#"txt"];
FILE *dic = fopen([filePath cStringUsingEncoding: NSUTF8StringEncoding], "r");
And it works now without any problem! It's just amazing!
ps I decided to write this answer in case it will help someone like me and will save them some time. If you know how to change working directory in XCode 9 for iOS, please, leave me a comment - now I am really curious why I can't find it.

"Error C1083: Cannot open source file" Shouldn't Be Looking For The File At All

I was trying to #include a cpp file with some functions so I can use that cpp file later with other projects. It gave me an 'already defined in .obj' error and since then that .cpp file was like binded with my project. (I understood that's not the way, the answer here helped me with the already defined)
If I exclude the .cpp file from the project, remove it from the directory and remove the #include line it still looks for it:
c1xx : fatal error C1083: Cannot open source file: 'std.cpp': No such file or directory
Diagnostic:
Outputs for D:\MY DOCUMENTS\C#\PROJECT\D3DTESTC++\COWS AND BULLS\CBMAIN.CPP|D:\MY DOCUMENTS\C#\PROJECT\D3DTESTC++\COWS AND BULLS\STD.CPP: (TaskId:15)
It shouldn't be looking for the std.cpp at all, I removed it! So is there a way I can reset the project and recompile so that the program doesn't look for it? I already tried Rebuild and Clear -> Build Project
When I ran across a similar problem with VS Express, I wound up having to open up the the .vcxproj file (which is just XML), and remove the offending
< ClInclude Include="FILEPATHANDNAME" > tags.
Many of the solutions here will not work
Fullproof method:
Open the vxproj file that is giving you trouble in a text editor.
remove all references to the file it cannot find.
OK, I have no idea how I did it but I'm still going to try to write what I did.
Save all and Close solution
Open the .vcxproj file (not .sln)
Build -> Clean [Project Name]
Save all and Close
Open the .sln file again.
Build -> Project Only -> Clean Only [Project Name]
Build -> Project Only -> Build Only [Project Name]
That's exactly what I did and worked for me. I think the main thing to do is clean, save, close, open, build, but I'm not sure.
In Solution Explorer you can select/deselect option "Show All Files".
Try both options and make sure excluded file is not included in project for both of them.
That's what I had:
I used "Show All Files" option (so you can see all the files in project directories). I excluded one of my .cpp files from project. However, it behaved as this file is in project.
That's how I managed to fix it:
I switched "Show All Files" off and saw this file still belongs to project! So I excluded this file once again.
As I see, that's a known issue.
This worked for me, hope it will be useful for someone else.
Try to verbose builder output to see exact steps of what's going on. I suppose, you use Visual Studio, right?
Go to menu "Tools -> Options"
In options dialog, select "Projects and Solutions -> Build and Run"
Change current mode of "MSBuild project build output verbosity" from "Minimal" to something like "Diagnostics" or "Detailed".
Rebuild your project and investigate Output windows
Builder dump should shed more light on your current settings (I suspect you have more references to that file than you expect)
This happened to me because I renamed folder from inside the IDE. None of the above solutions worked. The only way to fix this is by opening vcproj in notepad and you should see the offending files in the <ItemGroup>. Just delete those lines.
Or sometimes, like in my case, the issue is simply in the naming of the folders in the location. I had a very long path with folders that I like to name with special characters so they show up at the top and it's easy to access them.
As soon as I put my solution in a folder just in D: drive, the issue was gone.
When I renamed a file, I found I had to go to SolutionExplorer, Source File, select the file, first exclude from Project, then re-add it to project, and rebuild the solution it lives in. It was still showing up as the old file name under Source Files for me.
I had the same problem, but I had another .sln worked fine. After tooling around with the Project->Properties-> to make them look identical, nothing worked. I opened both .vcxproj files and copied the contents of the working version into my non-working version. (I noticed that the two files had different lengths. The non-working version was longer by about 20 lines.) I just changed the RootNameSpace to the non-working version's name. I saved the non-working file and presto! It worked.
I removed those sources from Project and re-added them. Somehow, references were messed up after a hurry project refactoring.
For people having problem related to "error C1083: Cannot open source file":
Error is caused by settings in *.vcxproj file. Probably you deleted/moved source file by file explorer, not by Visual Studio's "Solution Explorer". Thus, your *.vcxproj file is corrupted. Fix is to manually correct settings in *.vcxproj file.
How Visual Studio settings files work
Visual Studio saves solution's info into file. This file is usually in project's solution directory, has extension .sln and base name is same as name of solution, f.ex.:
NameOfSolution.sln
Similarly, project's info is saved into one file (each project has its own file). Base name of this file is name of project, extension is .vcxproj, and usually is located in subdirectory named as your project, f.ex.:
NameOf1stProject/NameOf1stProject.vcxproj
NameOf2ndProject/NameOf2ndProject.vcxproj
Both *.sln and *.vcxproj files are textual files. You can open them by using Notepad.
How to fix problem
Find *.vcxproj file responsible for your project.
If you don't know where it is, open in Notepad the *.sln file of your solution. Search for name of your solution. You will find line like:
Project("{9AA9CEB8-8B4A-11D0-8D22-00B0C01AA943}") = "NameOf1stProject", "NameOf1stProject\NameOf1stProject.vcxproj", "{A8735D0A-25ED-4285-AB8F-AF578D8DB960}"
Value under "NameOf1stProject\NameOf1stProject.vcxproj" is location of *.vcxproj file of your project.
Open found *.vcxproj file by text editor (f.ex. Notepad).
Search for line on which is filename you are struggling with.
Example: if you are looking for "RemovedFile.cpp", then you should find line:
<ClCompile Include="RemovedFile.cpp" />
Delete that line.
If you have opened Visual Studio, it asks you if it should refresh solution - select yes. If it is not opened - just start using it.
In case of any problems, try to rebuild solution (top banner -> Build -> Rebuild Solution)
In my cases, it worked. 30 mins of trying to fix, <1 minute of fixing.
This helped in my case. To sum it up, my path to the project was too long, so I moved my project to something shorter i.e. D:\my_project and everything worked in a blink of an eye.
I had this same problem, but for me the issues was that I was using Bash on Windows (WSL) to clone the repository and then using VS to compile.
Once I deleted my clone and used Windows command line (cmd.exe) to clone the repo then the error 1083 went away.
This is caused by not removing/deleting the file properly. Go to Solution Explorer, select your solution, at the left corner, activate the icon: show all files.
(if you already removed the problem file, restore it from recycle bin)
Select the problem file, do remove and delete from within Solution Explorer and you should not have this problem. And remember to do it the proper way from now on.
This is on MS 2010
If you have that file in your project directory but you still got the error, on your IDE go to Solution explorer--> Remove that file-->then open the project directory on your file explorer-->Select that file and drop it on a specific location in IDE solution explorer. I fixed it this way. I use the Windows platform.
I got this error when I got a code from my peer and I tried directly running it on my system. Ideally to avoid such errors, I should have just copied the source and header files and should have created the VS solution of my own.
To resolve the errors I removed the files from the Solution Explorer and added them again. Following image shows the Solution Explorer window.
The remove option comes after right clicking on the file names.

VC2008 compiler errors opening sbr files (C2418 C1903 C2471)

EDIT: See my answer below for the hotfix.
ORIGINAL QUESTION:
In setting up for our boat-programming adventure I have to set up source control and fix project files for a team to use them. (the project was previously only being worked on by one person who took shortcuts with setting up the project includes, etc)
I am fixing those SLN and Proj files. When trying to do a build on an external USB drive (I have not tried it on the primary hard drive) I am getting odd errors (lots of them for various files):
fatal error C1083: Cannot open
compiler generated file:
'.\Debug\.sbr': Permission
denied
These files are referenced in the vcproj file with relative paths in double quotes:
RelativePath="..\..\Source\.cpp"
I get the same errors form within a sln file in the IDE or if I call msbuild with the sln file.
The files are kind of "shared" for a few sln files (projects).
The person who originally created the SLN files is not known for being a wizard at configuring MSDev or making things work for teams.
Is this an issue with the way the source files are referenced? Any suggestions on how to fix these?
This URL does not seem to have helpful information:
Fatal Error C1083 on MSDN
Note - there were/are still hardcoded paths in the proj file, but i don;t see them for these files. They were mostly for the include and lib dirs. I think I removed them all.
I also get these errors:
..\..\Source\.cpp : error C2471:
cannot update program database '\debug\vc90.pdb'
..\..\Source\.cpp(336) : fatal
error C1903: unable to recover from
previous error(s); stopping
compilation
..\..\Source\.cpp(336) : error
C2418: cannot delete browser file:
.\Debug\.sbr
Title: You may receive a "PRJ0008" or "C2471" or "C1083" or "D8022" or "LNK1103" or similar error message when you try to build a solution in Visual C++
Symptoms:
D8022 : Cannot open 'RSP00000215921192.rsp'
PRJ0008 : Could not delete file 'vc90.idb'.
C1083 : Cannot open program database file 'vc90.pdb'
C2471 : Cannot update program database 'vc90.pdb'
LNK1103 : debugging information corrupt.
Cause:
This problem occurs when all of the following conditions are true:
You have a solution with more than one project in it.
Two or more of the projects are not dependent on each other.
You have parallel builds enabled. (Tools -> Options: Projects and Solutions, Build and Run: "maximum number of parallel project builds" is set to a value greater than 1)
You are building on a system with multiple CPUs (cores).
Two or more of the non-dependent projects are configured to use the same Intermediate and/or Output directory.
A specific race condition in mspdbsrv.exe remains uncorrected.
Resolution:
To resolve the problem do one or more of the following:
Reconfigure the non-dependent projects to specify an Intermediate and Output directory that is different from one another, e.g. Output Directory = "$(SolutionDir)$(ProjectName)\$(ConfigurationName)", Intermediate Directory = "$(OutDir)".
Adjust your solution's project dependencies (Project -> Project Dependencies...) so that each is dependent on another.
Disable parallel builds.
Add the "/onecpu" boot option to your boot.ini file.
Change you BIOS settings to enable/use only one CPU.
File a problem report with Microsoft Technical Support and keep bugging the crap out of them until they eventually fix mspdbsrv.
Status:
The problem is a combination of both a user project configuration error as well as a race condition in Microsoft's "mspdbsrv.exe" utility that does not properly handle more than one thread calling it at the same time for the same file resulting in the file's HANDLE being left open.
Additionally Visual Studio itself and/or its build system (VCBUILD and/or MSBUILD) (or all three!) should be made smart enough to detect and alert the user of such user errors so that corrective action can be taken.
This problem has been around for a LOOOOOONG time.
Applies to:
Microsoft Visual C++ 2005
Microsoft Visual C++ 2008
Others?
Respectfully submitted:
"Fish" (David B. Trout)
fish#infidels.org
p.s:
You're welcome. :)
Hmmm.
Perhaps:
http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/0ceac3c6-62f6-4fdf-82e1-d41e1b4fcd20/
there is a hotfix from MS
http://code.msdn.microsoft.com/KB946040
http://support.microsoft.com/kb/946040
That might be my problem. I think it might only be on one machine I have.
EDIT:
I downloaded and ran the hotfix installer. It seems to have fixed it.
I get this same error when I physically remove a file from disk, but leave it in VS. In VS2005 it would give a much better : fatal error file not found. I think this is a bug in VS2008. The hotfix mentioned above didn't help me.
In my case it was my virus package (Trend Micro) causing all the problems. I added my Dev folders to the Ignore/White lists to solve the problem
delete your debug folder and build your project agian.
Occastionally my Visual Studio will suddenly decide something like this. I have found it maybe help to toggle to release, do a full rebuild, then toggle back to debug.

VS2008 win32 project defaults - remove default precompiled headers

I have been through every option to try to find a way to get the IDE to let me create a new win32pject without precompiled headers. I have read every thread on this forum with the words "precpmpiled headers" in it and the closest I got was:
Precompiled Headers
Using 2008 pro (not express, althought the behaviour seems to be similar) I go to:
File -> New -> Project
This opens the New Project dialog in which I select Visual C++ Win32 Project, enter a name and hit OK.
THen I get the "Win32 Application Wizard". With the Application Type set to "Windows Application", the application settings pane will not allow me to uncheck the pre-compiled headers. THe check box is greyed out. IF I choose "Console Application" I can uncheck it, but I am creating a GUI app.
WHen I click Finish I get 6 yards of code in xxx.cpp, four header files and the obligatory stdafx.cpp.
Perhaps I could remove and delete all this stuff and the go into the properties and turn off PCH, but thats a hasssel for the many small project examples I want to write.
I just want an empty project that will compile to a win32 app, so how do i change the PCH default to NONE?
You could make your own template to do this, or you could edit the default one. The relevant wizard can be found here:
C:\Program Files\Microsoft Visual Studio 9.0\VC\VCWizards\AppWiz\Generic\Application
Obviously if you're gonna edit the default template, backup the folder first.
I'll show you how to get started on editing it.
First of all you need to tell the wizard script that you don't want precompiled headers. Edit this file in your favourite text editor:
\scripts\1033\default.js
Find this line:
var Pch = wizard.FindSymbol("PRE_COMPILED_HEADER");
and comment out some of the lines below it like this:
// if ((strAppType == "LIB" || ((strAppType == "CONSOLE") &&
// !wizard.FindSymbol("SUPPORT_MFC") && !wizard.FindSymbol("SUPPORT_ATL"))) && !Pch)
{
AddFilesToProjectWithInfFile(selProj, strProjectName);
SetNoPchSettings(selProj);
}
// else
// {
// AddFilesToProjectWithInfFile(selProj, strProjectName);
// SetCommonPchSettings(selProj);
// }
Now open this file:
\templates\1033\Templates.inf
and find the first occurrence of [!else] and delete these 3 lines below it:
stdafx.h
targetver.h
stdafx.cpp
This will give you a project without stdafx.cpp/.h or targetver.h, and the CPP file will not try to use a PCH. However it won't build because we haven't added any #includes to the appropriate header files. I'll leave that for you to figure out :)
(you can edit the files that get generated automatically by modifying the files in \templates\1033)
either choose an empty project, or create your own wizard in which you use a template. Since you say you don't want to change properties the whole time, I'd also strongly suggest using property sheets (vsprops). This way, you create an empty project, add the property sheets you want, and you'r ready to go. No more fiddling with properties, and each project uses the same set.
Mark the "Empty Project" check box in the "additional options", in the Application Settings dialog.
The "Empty Project" option will create a project without precompiled headers. At least, this is what I get on Visual Studio 2008 SP1.
It's true that the "Use precompiled headers" remain checked, but the project will have the property UsePrecompiledHeader="0" and the wizard won't create the files.
I'm jumping way late on this bandwagon, as I'm having the same issues for VS2010.
I'm not sure if this solution would apply for VS2008.
Since there are no settings or options under tools which would enable me to default to an empty project, I searched around and found the following:
in the folder
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\VCWizards\AppWiz\Generic\Application\html\1033
there is a file named default.htm
in the </HEAD> section, there are two lines:
<SYMBOL NAME="EMPTY_PROJECT" TYPE=checkbox VALUE=false></SYMBOL>
<SYMBOL NAME="PRE_COMPILED_HEADER" TYPE=checkbox VALUE=true></SYMBOL>
which I replaced with
<SYMBOL NAME="EMPTY_PROJECT" TYPE=checkbox VALUE=true></SYMBOL>
<SYMBOL NAME="PRE_COMPILED_HEADER" TYPE=checkbox VALUE=false></SYMBOL>
(in other words, I just switched true and false on those lines)
and now I have an empty project by default when I create a console app.
I don't know the repercussions as to what it will affect when I do something other than console apps, but since I saved the original file, I can just revert to the old M$ settings.
You can just select 'empty project' under 'additional options'. Then you get a project with no precompiled headers, and no autogenerated files.
I don't know what it is with Microsoft's obsession with forcing precompiled headers even in the smallest test project. Presumably it's based in the same philosphy that gave us the macro hell that is windows.h, or the way even an empty project overrides two dozen project settings, making property sheets almost useless.
I suspect there's simply a strong mafia inside Microsoft's developer division, who's doing everything they can to prevent Visual Studio from becoming a useful tool for C++ developers. So far, they're doing a very good job of it.