The project contains only C++ source. There is no custom-build item like a parser or lexer file.
the diagnostic output mentions something like:
fileName.cpp will be compiled because the tracking log is not available.
There is another line in the diagnostic output, which I'm curious about:
Source compilation required: input C:\<install_dir>\MSVCPRTD.LIB is newer than output .
Anybody any clue?
The problem was that the source tree has been created using git running under bash_on_windows subsystem. There was a directory called AUX which cannot be accessed from within windows. Removing this AUX directory AND copying the entire tree to some other place resolved this problem.
Related
So I've look at a few questions here which popped up after a search, but I still haven't managed to get this to work.
My project has two files, main.cpp and shader.comp.
The shader needs to be compiled before the main program is ran and I have a small .bat script that does just that. It's set to run as a pre-build event.
However, if I edit shader.comp and leave main.cpp unmodified since I last ran the project, there is no need to rebuild the project (according to VS anyway), so there is no need to run any pre-build events and my shader doesn't get compiled.
Is there a way to tell VS2017 (or VS2019) that if some file is modified, then run something, or at least a way to add an arbitrary file to list of files that VS checks against when deciding whether to run the build or not?
I've tried setting "Exclude from build" to "No" in the file properties, but no matter what "Item type" I choose, editing just the shader won't trigger the rebuild.
It's possible to define the shader that needs to be compiled as Custom Build Tool in the properties of the file (as Item Type). This will open another menu in the properties where cmd script and similar can be written.
In this particular case, value for Command Line was:
glslangValidator.exe -V -o "%(RootDir)%(Directory)%(Filename).spv" "%(FullPath)"
And the Outputs:
%(RootDir)%(Directory)%(Filename).spv
In short, if file defined in Outputs doesn't exists or is older than the owner of this property (the file that needs to be compiled), the Command Line argument will be ran in cmd.
Official documentation has more info on this.
Maybe you can get some help from this issue. You can specify the files for VS Up-To-Date check.
<Project...>
...
<ItemGroup>
<UpToDateCheckInput Include="shader.comp" /> <!--when this file is in the project folder-->
<!--<UpToDateCheckInput Include="path/shader.comp" />-->
</ItemGroup>
</Project>
And this script into your project file. Then if there's any change to shader.comp file,VS will build your project.
Note: In this way, if you only change the shader.comp file , but not change the source file(xx,cpp), the build will start but vs will skip the compile target of C++ source code. Only when you modify the source code main.cpp, then VS will run the pre-build event and compile the code. Let me know if it's what you want, hope i didn't misunderstand anything :)
I have a custom MSBuild target included in my C++ project that produces a data file in the $(OutDir) folder for each item of a given item type. I have the item type hooked up with a property page schema so you can select it on files in the solution explorer and my target declares input and outputs so incremental builds work. I have also added my target to the $(BuildDependsOn) property so it is automatically evaluated during the Build target Visual Studio invokes.
Everything seems to work except for one thing: If I delete one of my output data files in the $(OutDir) and then build Visual Studio does nothing and says my project is up to date. If I delete the exe file the project produces or touch the modified time of one of the MSBuild scripts Visual Studio re-evaluates the targts and finds the output file is missing, causing it to be re-built using my target.
From the MSBuild diagnostic logging it seems like Visual Studio is internally maintaining some list of output files and input files that it checks to avoid evaluating the MSBuild script at all. How do I add my output files to this list?
MsBuild/VS indeed have a mechanism to determine what is up-to-date with respect to the input files, it revolves around an executable tracker.exe which scans .tlog files to figure out what a project's output files are. There might be more to it, and if you look around on the internet you can probably get more info about this.
But the thing is you don't really need to understand every single detail of it: you can find a simple usage example for it when inspecting how the built-in CustomBuildStep works and apply that to your case. I'll briefly explain how I got to this because I think it might be useful for you as well in dealing with msbuild questions like these.
If you add
<ItemDefinitionGroup>
<CustomBuildStep>
<Command>echo foo > $(OutDir)\foo.txt</Command>
<Outputs>$(OutDir)\foo.txt</Outputs>
</CustomBuildStep>
</ItemDefinitionGroup>
either manually or via the project's property pages for Custom Build Step you'll see the beahviour is eactly what you need: if foo.txt is deleted a build will start, while a build is marked up-to-date if it is not (well, and when the rest of the outputs are also up-to-date).
Hence the key is to do what CustomBuildStep does under the hood, and figuring that out is just a matter of using your tool of choice to search all occurrences of CustomBuildStep in all files under C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120 (adjust path for platform/VS version used).
This leads us to Microsoft.CppCommon.Targets where the target named CustomBuildStep (mind you, that's the same name as the entry in the ItemDefinitionGroup above) invokes the actual CustomBuildStep command. It also has this particularily interesting bit:
<!-- Appended tlog to track custom build events -->
<WriteLinesToFile Encoding="Unicode"
File="$(TLogLocation)$(ProjectName).write.1u.tlog"
Lines="#(CustomBuildStep->'^%(Identity)');#(CustomBuildStep->MetaData('Outputs')->FullPath()->Distinct())"/>
So this writes the path of the Outputs to a .tlog file in the directory used by the tracker and makes it work as desired. Also see here for more information about the format.
tl;dr Use WriteLinesToFile to append full paths of your targets' outputs to a file like $(TLogLocation)$(ProjectName).write.1u.tlog. I'm saying like because write.tlog, write.u.tlog etc also work.
Visual Studio uses something called Visual Studio Common Project System (CPS) (https://github.com/Microsoft/VSProjectSystem) (VS 2017)
to manage projects, including build process.
Within CPS anything that implements IBuildUpToDateCheckProvider interface can be used
as a 'UpToDateChecker' for a project.
'UpToDateChecker' is invoked before invoking MsBuild. Its main purpose is to determine whether or not invoke MsBuild to build project, or to mark project as 'Up To Date' and skip msbuild all along.
This 'UpToDateChecker' is exactly what prints into diagnostic build output:
1>------ Up-To-Date check: Project: "ProjectName", Configuration:
Debug x86 ------ Project is not up-to-date: build input 'header.h' was
modified after build output 'a.out'. Input time: 12/27/2018 4:43:08
PM, Output time: 1/1/0001 2:00:00 AM
As for C++ Projects, for VS 2017 its default 'UpToDateChecker' is VCProjectBuildUpToDateCheck
( Microsoft.VisualStudio.Project.VisualC.VCProjectEngine.dll ).
As starter, it looks into tlogs directory ( usually something like Debug\x86\.tlog) for these files:
.lastbuildstate
unsuccessfulbuild
all '.read..tlog' - input files, marked as 'build input' in diagnostic build output
all '.write..tlog' - output files, marked as 'build output' in diagnostic build output
There's actually more checks, but most fails occur when checking these 4 types
The original question here relates to C++ projects, but for anyone finding this while searching for information about modern (SDK-style) C#/VB/F# projects, you can customise Visual Studio's fast up-to-date check as described in this document:
https://github.com/dotnet/project-system/blob/master/docs/up-to-date-check.md
In a nutshell, you specify inputs and outputs as items:
UpToDateCheckInput — Describes an input file that MSBuild would not otherwise know about
UpToDateCheckBuilt — Describes an output file that MSBuild would not otherwise know about
It can be very helpful to increase the diagnostic logging level for the up-to-date check via this setting:
You can find out why a project is being rebuilt by enabling the verbosity of the fast up to date checker in the registry key:
New-ItemProperty `
-Name U2DCheckVerbosity `
-PropertyType DWORD -Value 1 `
-Path HKCU:\Software\Microsoft\VisualStudio\14.0\General -Force
You should be able to see in the build log messages like
Project 'Caliburn.Micro.Silverlight.Extensions' is not up to date. Project item 'C:\dev\projects\Caliburn.Micro.Silverlight.Extensions\NavigationBootstrapperSample.cs.pp' has 'Copy to Output Directory' attribute set to 'Copy always'.
[1] https://blogs.msdn.microsoft.com/kirillosenkov/2014/08/04/how-to-investigate-rebuilding-in-visual-studio-when-nothing-has-changed/
To enable logging for old-style projects (i.e. non-SDK-style projects, common in the .NET Framework era):
Open a "Developer Command Prompt" for the particular version of Visual Studio you are using.
Enter command:
vsregedit set "%cd%" HKCU General U2DCheckVerbosity dword 1
The message Set value for U2DCheckVerbosity should be displayed.
Run the same command with a 0 instead of a 1 to disable this logging.
More information at: https://github.com/dotnet/project-system/blob/main/docs/up-to-date-check.md#net-framework-projects
I recently tried to use the vs-tool found here done by James Allison. This works well for the *.html and *.js builds, but it fails for the *.bc builds. The error message presented is "GCCLIB : error root: rcs: No such file or directory ("rcs" was expected to be an input file, based on the commandline arguments provided)" which i have no idea what it means, and googling the error does not yield any results.
Any thoughts or ideas ?
Open the .vcxproj file for the project in a text editor and see if under the emscripten build configurations there are tags that are not relevant.
For example I had a "ResourceCompile" tag which always led to an error regarding rc.exe being missing.
Similarly I also had "BrowseInformation" tags.
This happens when you create your Emscripten configuration from an configuration which had these additional tags for example x64. Probably a bug in vs-tools. Ideally it should be skipping these tags.
I use CMake generated solution for Visual Studio 2010.
In my solution I have several lib projects and one exe project.
For Debug build configuration I use output names like lib1_d.lib, lib2_d.lib etc...
For Release build configuration I use lib1.lib, lib2.lib ...
thanks to CMake I have one extra build configuration I use - RelWithDebugInfo. I use same output names for this build configuration as for Release.
Now here is the problem:
Assuming everything is cleaned.
I hit F5 (run / start debugging) RelWithDebugInfo. All project are built (exe is depending on them) and project runs successfully.
I switch to Release and hit F5 again. All project are built and project runs successfully. (libraries in output directory are overwritten)
I switch back to RelWithDebugInfo and hit F5. VS quickly goes through and gives All outputs are up-to-date. ... Build succeeded. And DOES NOT overwrite lib files in output directory. So application crashes because it uses libraries for other build configuration.
This problem occurs for both ordering Release->RelWithDebugInfo and RelWithDebugInfo->Release
I haven't find a solution, how to add other prefix to RelWithDebugLibraries my SO question
Is there a way, to force Visual Studio 2010 to always overwrite outputs? Preferably by some flag which I can provide from CMake.
The VS build system solves this problem by using different build directories for different configurations. By default, 32-bit Debug output goes to the Debug directory, Release output goes to the Release directory, 64-bit Debug output goes to x64\Debug directory, etcetera. This way different configurations never step on each other's output files.
Looks to me like the mistake you made with your added RelwithDebugInfo configuration is that you didn't modify the output file names. So the build system sees an up-to-date output file from another configuration and doesn't think it necessary to rebuild them.
Coming up with variations of build output file names does get to be impractical once you go past two, do consider the VS-way to do this.
When I'm trying to build my VC++ code using 2010 I'm getting the error message
> C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 1.
Please tell how to overcome this?
Navigate from Error List Tab to the Visual Studios Output folder by one of the following:
Select tab Output in standard VS view at the bottom
Click in Menubar View > Output or Ctrl+Alt+O
where Show output from <build> should be selected.
You can find out more by analyzing the output logs.
In my case it was an error in the Cmake step, see below. It could be in any build step, as described in the other answers.
> -- Build Type is debug
> CMake Error in CMakeLists.txt:
> A logical block opening on the line
> <path_to_file:line_number>
> is not closed.
error MSB6006: "cmd.exe" exited with code -Solved
I also face this problem . In my case it is due to output exe already running .I solved my problem simply close the application instance before building.
I had the same problem today, while I was upgrading some VC6 project to VC2012.
In my case, it was because some of the operation in Custom Built Steps failed.
In project properties, go to Custom Build Step, you can see there maybe some something in command line edit box. Open a windows prompt and paste the command to it. Run, check if there is something wrong and fix it.
If there is no command line in the project property Custom Built Step, maybe you should check properties of every single file of the project.
If the command line has some macro, replace it with an actual value.
Or you can echo the command in VS output window:
cd %(somedir)%
echo %(somedir)%
You won't miss it this way.
I solved this. double click this error leads to behavior.
open .vcxproj file of your project
search for tag
check carefully what's going inside this tag, the path is right? difference between debug and release, and fix it
clean and rebuild
for my case. a miss match of debug and release mod kills my afternoon.
<Command Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">copy ..\vc2005\%(Filename)%(Extension) ..\..\cvd\
</Command>
<Command Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">copy ..\vc2005\%(Filename)%(Extension) ..\..\cvd\
</Command>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">..\..\cvd\%(Filename)%(Extension);%(Outputs)</Outputs>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">..\..\cvd\%(Filename)%(Extension);%(Outputs)</Outputs>
<Command Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">copy ..\vc2005\%(Filename)%(Extension) ..\..\cvd\
</Command>
<Command Condition="'$(Configuration)|$(Platform)'=='Release|x64'">copy %(Filename)%(Extension) ..\..\cvd\
</Command>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">..\..\cvd\%(Filename)%(Extension);%(Outputs)</Outputs>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Release|x64'">..\..\cvd\%(Filename)%(Extension);%(Outputs)</Outputs>
</CustomBuild>
Actually Just delete the build ( clean it ) , then restart the compiler , build it again problem solved .
I also faced similar issue.
My source path had one directory with 'space' (D:/source 2012). I resolved this by removing the space (D:/source2012).
For the sake of future readers. My problem was that I was specifying an incompatible openssl library to build my program through CMAKE. Projects were generated but build started failing with this error without any other useful information or error. Verbose cmake/compilation logs didn't help either.
My take away lesson is that cross check the incompatibilities in case your program has dependencies on the any other third party library.
Simple and better solution :
%WINDIR%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe MyProject.sln
I make a bat file like this
%WINDIR%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe D:\GESTION-SOMECOPA\GestionCommercial\GestionCommercial.sln
pause
Then I can see all errors and correct them. Because when you change the folder name (without spaces as seen above) you will have another problems. Visual Studio 2015 works fine after this.
When working with a version control system where all files are read only until checked out (like Perforce), the problem may be that you accidentally submitted into this version control system one of the VS files (like filters, for example) and the file thus cannot be overridden during build.
Just go to your working directory and check that none of VS solution related files and none of temporary created files (like all moc_ and ui_ prefixed files in QT, for example) is read only.
I was in a similar situation to the one described by "irsis".
I configured the project through CMAKE, and in CmakeList, I linked the OpenCV library to the project. However, when I updated the OpenCV version for another project, the path was changed and error occurred.
Check path of all related library.
Another solution could be, that you deleted a file from your Project by just removing it in your file system, instead of removing it within your project.