I am probably missing something obvious - but I have been stuck for a while on this issue. I am compiling a Visual Studio project on the command line using MSBuild. Basically like this:
CALL vcvars32.bat
MSBuild myproject.sln /m /t:rebuild /p:Configuration=Release /verbosity:m
But this gives me an error: fatal error C1083: Cannot open include file 'winsock.h': No such file or directory
But if I check the environment variable INCLUDEafter the vcvars32.bat call the directory containing 'winsock.h' is in the list - so I definitely have this file in the SDK.
In addition if I change verbosity of MSBuild to detailed I can see the full compile command used. If I copy that and run it in the console the same cpp file compiles without any problem.
Any idea whats different inside the MSBuild context ?
Solved it, adding /p:useenv=true make MSBuild use the INCLUDE environment variable.
( Still a bit unsure why that had to be done though, since I can't recall having needed that earlier for command line builds. )
Related
I'm struggling with this for a long time now.
The setup:
c# project
c++ project
c# project has a reference for the c++ project with the following lines:
<ProjectReference Include="projectB.vcxproj">
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
<OutputItemType>Content</OutputItemType>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</ProjectReference>
This works from withing visual-studio.
This works when using devenv from command line.
When using msbuild from command line - the output file of the c++ project is not copied over into the output directory of the c# project.
I wasn't able to fix that using msbuild. Read a lot about it, nothing worked. Tried to debug in using diag verbosity - but logs of msbuild and visual-studio are very different...
I can't turn to using devenv as the build machine doesn't have valid visual-studio.
In msbuild log with diagnostic verbosity I see:
Target "GetCopyToOutputDirectoryItems" skipped. Previously built successfully.
This is where in the visual-studio log - it looks different - and actually works on copying the referenced native files to the c# output directory.
Perhaps something related with build order?..
In msbuild log - I also see:
Target "_CopyOutOfDateSourceItemsToOutputDirectoryAlways" skipped, due to false condition; ( '#(_SourceItemsToCopyToOutputDirectoryAlways)' != '' ) was evaluated as ( '' != '' ).
While in the visual-studio build log I see this target executed (it comes right after GetCopyToOutputDirectoryItems target)
Update 3:
It seems that previous solutions cause unwanted side-effects such as breaking the build when running multi-threaded builds.
Current solution, that does seem to work is to add:
<Targets>Build;BuiltProjectOutputGroup</Targets>
to the ProjectReference section.
Update 2:
Changing:
Targets="%(_MSBuildProjectReferenceExistent.Targets)"
to
Targets="%(_MSBuildProjectReferenceExistent.Targets);GetTargetPath"
in C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets, in the MSBuild task preceded by the comment Build referenced projects when building from the command line. - did the trick.
However, I have no confidence in this solution, as I don't understand the entire build process. This is just a guess.
Update 1:
using /p:DesignTimeBuild=true affects dependency build order. Can't work. Continue investigation...
Possible solution 1:
After putting a lot of messaged into C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets
I finally got to the following:
QUIRKING FOR DEV10
I'm still not exactly sure what that is all about, and I saw that the developers plan to remove this quirk (see https://github.com/Microsoft/msbuild/issues/1890).
Suddenly DesignTimeBuild caught my eye in the following line:
<Output TaskParameter="TargetOutputs" ItemName="_ResolvedProjectReferencePaths" Condition="'%(_MSBuildProjectReferenceExistent.ReferenceOutputAssembly)'=='true' or '$(DesignTimeBuild)' == 'true'"/>
I know that inside visual-studio this work. Googling got me to https://github.com/Microsoft/msbuild/wiki/MSBuild-Tips-&-Tricks.
From there the path was short to adding /p:DesignTimeBuild=true to the msbuild command line.
That made it work. The referenced assembly was copied over.
I don't think this should be the solution, but it works, and don't seem to break anything else (yet).
Any other suggestions would be welcome.
I have cpp file called funner.cpp which i compiled down to a dll file by using the following command: (using microsofts CL compiler, btw)
cl /LD funner.cpp
that generated the following files: funner.lib, funner.dll.
i then created another cpp file called mainer.cpp which calls a function within the dll.
i compiled that file using this command:
cl mainer.cpp /link funner.lib
that, then, generated an executable file, called mainer.exe.
When i run mainer.exe the program runs as expected and i get no errors what so ever. (as long as the funner.dll file is in the same directory)
however i would like to move the funner.dll to another directory somewhere else, say:
c:\my_dlls\
so i did that and then i added the folder to my system PATH variable.
i then tried running the executable but it threw me an error saying that the dll was missing?
but doesn't windows search all the directories in the PATH variable for dlls ?
why cant it find my dll?
The command line does not receive the updated PATH until you close and reopen it.
Open a new command line and call the executable from there.
I have a C++ project, and I am transitioning from Visual Studio Solutions to SCons for builds, so Linux users can also build my code. This is my first foray into SCons, and it's working very well with simple projects. But, for this project, I have a nested directory structure:
main/
sub1/*.cpp
sub2/*.cpp
sub3/*.cpp
file1.cpp
file2.cpp
And I have the following SConstruct file:
env = Environment()
env['PCHSTOP'] = 'stdafx.hpp'
env['PCH'] = env.PCH('stdafx.cpp')[0]
env.Program('program', [
'file1.cpp',
'file2.cpp',
'sub1/file1.cpp',
'sub2/file1.cpp',
'sub3/file1.cpp'
])
Running scons from the command line causes the following error:
fatal error C1083: Cannot open include file: 'stdafx.hpp': No such file or directory
Obviously, this is an MSVC error. But this should be solvable with Scons, I'm just not sure how..
I Noticed that Visual Studio will copy all the *.obj files to a build directory before linking by default. I think this may be part of the solution, but again, I'm unsure.
What I AM sure of, is this is not the first time someone has come across this problem, but Google didn't turn up anything for me.
PS: Unlike in the example, none of the files have naming conflicts, and could theoretically be moved to a flattened folder structure by SCons without issue.
This looks like you'll have to specify the proper include paths in your Environment via the "CPPPATH" variable...but it's difficult to tell without seeing the full command line. Remember, that all SCons envs are clean initially. So, if you're in the wrong working directory, a simple "#include " doesn't find the header if it's in a different folder.
Have a look at SCons' UserGuide, chap. 14 "Hierarchical Builds", which might give you a few more ideas and insights, or come over to the User mailing list at scons-users#scons.org.
I have a project that I converted from a makefile that has a source file that expects the command line options from the compiler. For example for when the project was built with gcc if you did program --help it would spit out the gcc command line used to compile the program.
How can I do the same thing in Visual Studio, so that it spits out the cl command line used to compile the program? Basically I want to hit F7 (to build solution) and have the whole thing automated. I can't find a macro for it. Thanks
edit; I mean programatically, so for example I want when I run the program for its output to contain the cl.exe command string that is used. You can see the command line at Configuration Properties > C/C++ > Command Line > All Options but I can't find a macro for it or some way to encapsulate it in a file.
Since VS switched the underlying build system to MsBuild the command line as shown in that dialog is created programatically within VS only. It might not even be the exact command line passed to cl: MsBuild itself invokes CL via a task and as such there is no direct link with what is shown in VS nor is there a way to get the command line out of it.
Anyway, there is no such thing as the command line since each source file might have different options. Furthermore I doubt you want the full commandline including the absolute include paths etc. Nobody is interested in that. Now if you make clever use of the macros from http://msdn.microsoft.com/en-us/library/b0084kay.aspx you can sort of recreate the command line yourself since most options are there:
std::string CompilerCommandLineOptions()
{
std::string cmd;
#ifdef _CHAR_UNSIGNED
cmd += " /J";
#endif
#ifdef __cplusplus_cli
cmd += " /clr";
#endif
#ifdef _CPPRTTI
cmd += " /GR"
#endif
//etc
return cmd;
}
Note: are you sure it's worth the hassle? Is there really somebody interested in the command line? It's not even sufficient to build the project. Why not the linker options as well then?
A .vcxproj is a Visual Studio project in the MSBuild project format. You can build it by running msbuild.exe, devenv.exe, devenv.com, using the Visual Studio GUI or the MSBuild API.
Visual Studio GUI uses the MSBuild API. In doing so, it limits the MSBuild output.
If you want more details, change your user settings in Visual Studio:
Tools > Options > Project and Solutions > Build and Run > two verbosity settings
Detailed will show the cl.exe command lines.
The closest thing which I came across cl command line which msuild executes is "hacking" the rsp file used while calling cl.exe.
Using Override compiler solution, I changed ClCompile ToolExe to custom mycl.bat script and this script received an argument which was #tmp-1234xxx.rsp file. This rsp file contained whole command line except cl.exe path, something like -
rsp file
/P /DDEBUG Source.cpp
Then after making desired changes in the rsp file by calling a separate bash script which were very minor for me, I called cl.exe with contents of my rsp file. So, whenever user hits the build button, this script executes.
mycl.bat script
#echo off
SET PATH=%PATH%;/usr/bin //to call cygwin bash
set parameter=%1
set parameter=%parameter:~1% //to remove # in the beginning
c:/cygwin/bin/bash process.sh %parameter%
process.sh
iconv -f UCS-2 -t UTF-8 <$1 >$1.conv //file converted to UTF-8, else bash wasn't handling it well
contents=`cat $1.conv`
#Processing on file contents here
path/to/cl.exe $(contents)
Very nasty solution, but it worked for my use case. I wanted to change the names of the file on the go based on some logic.
The problem I faced is Visual Studio uses tlogs written by CL Task to check while file needs to to be rebuilt on incremental build and my target's tlogs files were not enough. There were tlogs of every command in batch and bash scripts but not for whole target. So, it was building whole thing on incremental builds also.
I have received a project from another. When I built, this error occured. I tried to search Google to solve this problem and I followed this link but no effect.
Try doing Rebuild instead of Build. If this doesn't work, try deleting or renaming the Debug and Release directories, and build again.
Keep in mind that Visual Studio often has 2 sets of Release and Debug directories - one set at the top level directory for the solution, and one at the directory for the project.
This could be due to the length of the path for the intermediate files.
The max path length for visual studio is somewhere around 256 characters.
Whilst considering path lengths don't forget that the compiler may use paths such as C:\folder1\folder2\folder3\..\..\folder1a\file.obj, which is longer than you expect for the file C:\folder1\folder1a\file.obj.
Inspect your project settings or build output to see what paths are being used, and perhaps try shortening them.
My problem was case sensitive in Windows 10 for partition e:
I have fixed with:
fsutil.exe file setCaseSensitiveInfo "e:\" disable
I faced the same problem, and it's because I changed my folder name.
ex: I build the solution when its folder name is 'Folder1' and then I close the entire solution and change my folder name into 'Folder2'. When I re-open the solution, and tried to build it, it has error "Fatal error C1083: Cannot open compiler intermediate file: '*\Folder1*.pch': No such file or directory"
But as satuon said, I tried to rebuild instead of build the solution, it's then working.