I'm using command line param Fo, command line is like this:
file1.c /ZI /nologo /W3 /WX- /Od /Oy- /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm /EHsc /RTC1 /GS /fp:precise /Zc:wchar_t /Zc:forScope /Gd /analyze- /errorReport:queue /bigobj /FdDebug\vc100.pdb /FoDebug\ /FaDebug\
But some files still are produced outside of Debug folder (exe, ilk, pdb)
What I'm doing wrong?
Those are files produced by the linker. You'll need to run it separately or use the /link compiler option so you can control its output. Use the /OUT option to set the .exe and .ilk locations, the /PDB option to set the .pdb location.
Because (like DCoder said) cl.exe passes any command line options after /link to the linker, you can do it in one line:
cl.exe <all your cl arguments here> /link user32.lib <and other lib here> /libpath:"C:\Program Files\Microsoft SDKs\windows\v7.0A\Lib\" /out:files\newfilename.exe
You can change files\newfilename.exe to be whatever you want. If you run from a batch file, you can do something like files\%1.exe and etc...
Well, I was looking for the same thing and I found everything in cl documentation. However this page was the first one in google while I was searching, so I am putting the reference here
/FA, /Fa (Listing File)
Specifying the Pathname
/Fd (Name PDB File)
/Fe (Name EXE File)
/FI (Name Forced Include File)
/Fm (Name Mapfile)
/Fo (Name Object File)
/Fp (Name .pch File)
/FR, /Fr (Create .sbr File)
/FU (Name Forced #using File)
/Fx (Merge Injected Code)
Related
I use cmake (3.23+) to generate solution files for MSVC (via CMakeLists.txt).
I'd like to enable static analysis for generated projects, and make it use my custom ruleset. I am aware that MSVC supports a CmakeSettings.json file that can do this, but I don't understand how it relates to CMakeLists.txt/how it should be included here.
I've tried to do it via command line parameters:
target_compile_options ( ${PROJECT_NAME}
PRIVATE /MP /analyze /analyze:ruleset ${CMAKE_CURRENT_SOURCE_DIR}/use-after-move.ruleset
)
But the compiler treats the ruleset as another .cpp file to compile. The generated command line looks like this:
CL.exe /c ...list of include directories... /Zi /nologo /W1 /WX- /diagnostics:column /MP /Od /Ob0 /D _MBCS /D WIN32 /D _WINDOWS /D "CMAKE_INTDIR=\"Debug\"" /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /GR /std:c++latest /Fo"editor-lib.dir\Debug\\" /Fd".\vsbuild\lib\Debug\editor-lib-d.pdb" /external:W1 /Gd /TP /analyze /errorReport:prompt path/to/use-after-move.ruleset ...list of source files...
I tried wrapping the /analyze:ruleset into double quotes, but with the same outcome. I also tried to wrapping it with single quotes which made it show up in the compile options, however like this:
'/analyze:ruleset' path/to/ruleset
I also might be using these options wrong as the analysis is not performed when I manually plug them in project properties. Analysis is only performed when I drop the /analyze:ruleset and keep in just /analyze (but then it defaults to Microsoft's All Rules).
I found an answer in this SO thread: How to add Property to Affect Code Analysis in CMake
Create user property sheet (saved as EnableUseAfterMoveAnalysis.props):
<Project>
<PropertyGroup>
<RunCodeAnalysis>true</RunCodeAnalysis>
<CodeAnalysisRuleset>path/to/use-after-move.ruleset</CodeAnalysisRuleset>
</PropertyGroup>
</Project>
And then in CMakeLists.txt bind it to the project using set_property:
set_property(
TARGET ${PROJECT_NAME}
PROPERTY VS_USER_PROPS "path/to/EnableUseAfterMoveAnalysis.props"
)
I downloaded the source code for a library that resembles the processing library but for c++ called libxd. I used CMake to generate project files for Visual Studio 2019 which worked successfully. When trying to compile the solution for all of the provided build modes, I get the following errors:
The first error invlaid numeric argument '/Wno-narrowing' is what I'm concerned about for now. I'm trying to figure out why this argument is being provided to the compiler. When looking in the properties window for the xd project in the solution I can see the command line arguments that are supposed to be provided to the compiler in the C/C++ > Command Line tab. I verified that there is no /Wno-narrowing option provided. When looking at the build output it can be seen that the option -Wno-narrowing is being provided to the compiler. Can someone help me figure out why this argument is being passed? I looked throughout the compiler properties window to see if I could see anything that would be affecting it but I can't see anything that would affect this.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\bin\HostX64\x64\CL.exe /c /IC:\dev\libxd\include /IC:\dev\libxd\lib\glad\include /IC:\dev\libxd\lib\glm /IC:\dev\libxd\lib\stb\include /IC:\dev\libxd\lib\glfw\include /Zi /nologo /W3 /WX- /diagnostics:column /Od /Ob0 /D WIN32 /D _WINDOWS /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /GR /Fo"xd.dir\Debug\\" /Fd"xd.dir\Debug\xd.pdb" /Gd /TP /errorReport:prompt -Wno-narrowing C:\dev\libxd\src\opensans.cpp
Tracking command:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Tracker.exe /d "C:\Program Files (x86)\MSBuild\15.0\FileTracker\FileTracker32.dll" /i C:\dev\libxd\build\xd.dir\Debug\xd.tlog /r C:\DEV\LIBXD\SRC\OPENSANS.CPP /b MSBuildConsole_CancelEventfa83e1bb599743cfa0c02eb67d579e28 /c "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\bin\HostX64\x64\CL.exe" /c /IC:\dev\Users\olive\Downloads\libxd\include /IC:\dev\libxd\lib\glad\include /IC:\dev\libxd\lib\glm /IC:\dev\libxd\lib\stb\include /IC:\dev\libxd\lib\glfw\include /Zi /nologo /W3 /WX- /diagnostics:column /Od /Ob0 /D WIN32 /D _WINDOWS /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /GR /Fo"xd.dir\Debug\\" /Fd"xd.dir\Debug\xd.pdb" /Gd /TP /errorReport:prompt -Wno-narrowing C:\dev\libxd\src\opensans.cpp
cl : command line error D8021: invalid numeric argument '/Wno-narrowing'
The command exited with code 2.
The error is caused because that's not a valid MSVC flag. The flag is there because the CMakeLists.txt file demands it:
set_source_files_properties(src/opensans.cpp PROPERTIES COMPILE_FLAGS -Wno-narrowing)
That project specifies what it supports for building under Windows and it's not MSVC.
Windows Prerequisites: mingw-w64 version >= 4.8.1
So you either need to build it in the supported way, or modify the build scripts to allow for MSVC.
That would entail figuring out what the flag does in gcc (disables diagnostic messages about narrowing issues) and finding the equivalent in MSVC, probably a /disable:nnnn variant, once you figure out the nnnn. Figuring that out should be relatively painless since MSVC will tell you that when you compile it - lots of Cnnnn - something to do with narrowing warning messages.
Or you could just disable the line that adds the flag (for MSVC builds only) and see if it still builds. Of course, in the spirit of open source, you should then notify the author what it took to get it going, they may be happy to support MSVC if the effort is not too high.
I need to compile a program automatically with different platform toolsets. The compilation is done using cl.exe and link.exe like so:
cl.exe file.c /GS- /PlatformToolset=vc140xp /analyze- /W3 /Gy /Zc:wchar_t /Gm- /Od /Zc:inline /fp:precise /D \"WIN32\" /D \"_WINDOWS\" /D \"_UNICODE\" /D \"UNICODE\" /errorReport:prompt /WX- /Zc:forScope /Gd /Oy- /Oi /MD /Fa\"\" /EHsc /nologo /Fo\"\" /Fp\"\" /diagnostics:classic /link %link_additional% /ENTRY:wWinMain /SUBSYSTEM:WINDOWS /MANIFEST:EMBED /NXCOMPAT /DYNAMICBASE \"kernel32.lib\" \"user32.lib\" \"gdi32.lib\" \"winspool.lib\" \"comdlg32.lib\" \"advapi32.lib\" \"shell32.lib\" \"ole32.lib\" \"oleaut32.lib\" \"uuid.lib\" \"odbc32.lib\" \"odbccp32.lib\" /DEBUG:NONE /MACHINE:%arch% /OPT:REF /SAFESEH /INCREMENTAL:NO /SUBSYSTEM:WINDOWS /MANIFESTUAC:\"level = 'asInvoker' uiAccess = 'false'\" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /TLBID:1\
I'm using the switch /PlatformToolset=vc140xp but, the cl.exe doesn't seem to reconginze it, i get an error:
Unknown Option: /PlatformToolset
Is there a way you can change toolset using cl.exe, without msbuild and vcproj ?
Just incase someone need it, i was able to solve this isuue. i added this option to cl.exe:
/D \"_USING_V110_SDK71_\"
And also i modified this option:
/SUBSYSTEM:WINDOWS
to
/SUBSYSTEM:WINDOWS,5.01
After the application runs succesfully on windows xp. You might encounter some problems if you are heavily useing crt in your exe, in my exe i only needed CRT to define Tls callbacks, they do not work without CRT, so i guess maybe this is why this worked for me
I have an MFC solution with 17 sub-projects. I just recently added another dll project and cannot get the executable to link to the renamed version of the library. In the settings for the dll projects in the solution, debug builds all have a 'D' appended to the output name to signify that it's the debug version. In some cases, we do that by changing the TargetName to $(ProjectName)D, and in other cases a post build event copies it from the build directory to the lib directory and renames it appending the 'D'. For this project, when I compile the dll I get the two files as expected: MultiLangD.lib and MultiLangD.dll. This is the linker command line for the dll project:
/OUT:".\Debug\MultiLangD.dll" /NOLOGO /DLL /MANIFEST
/ManifestFile:".\Debug\MultiLangD.dll.intermediate.manifest" /ALLOWISOLATION
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG
/PDB:"C:\WorkSpaces\WorkSpace_CFFT_II_i18n\CFFT_i18n_MBCS\CFFT\MultiLang\Debug\MultiLangD.pdb"
/PGD:"C:\WorkSpaces\WorkSpace_CFFT_II_i18n\CFFT_i18n_MBCS\CFFT\MultiLang\Debug\MultiLangD.pgd"
/TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\Debug\MultiLangD.lib" /MACHINE:X86
/ERRORREPORT:QUEUE
This is the compiler command line for the dll project:
/ZI /nologo /W3 /WX- /Od /Oy- /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D "_AFXEXT" /D
"_MULTILANGDLL" /D "_CRT_SECURE_NO_WARNINGS" /D "_WINDLL" /D "_MBCS" /D "_AFXDLL" /Gm
/EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /GR- /Yu"StdAfx.h"
/Fp".\Debug\MultiLangD.pch" /Fa".\Debug\" /Fo".\Debug\" /Fd".\Debug\vc100.pdb" /Gd
/analyze- /errorReport:queue
In the executable project I list MultiLangD.lib as an additional dependency to the linker, set "Link Library Dependencies" to no, and "Use Library Dependency Inputs" to yes. The MultiLang dll project is not set as a project dependency to the executable. Nevertheless, in the debug build, I get an error because the linker cannot find MultiLang.lib. This is the linker command line of the executable project:
/OUT:".\Debug\WinGFApp.exe" /INCREMENTAL /NOLOGO /LIBPATH:"..\Lib"
/LIBPATH:"..\Student\lib" /LIBPATH:"C:\Program Files (x86)\Microsoft DirectX SDK (March 2009)\Lib\x86"
"MultiLangD.lib" "datastored.lib" "shlwapi.lib" "ws2_32.lib" "MdxReadd.lib" "winmm.lib"
"dxguid.lib" "dxerr9.lib" "dinput8.lib" "Messagingd.lib" "dtccd.lib" "Version.lib"
"SerialTCIMD.lib" "geosrvdll.lib" "NetworkUIDMD.lib" "amp2.lib" "idmmib.lib"
"vmfr2.lib" "d3dx9.lib" "comsuppwd.lib" "vmf_net_db.lib" "jvmfd.lib"
/NODEFAULTLIB:"libc" /NODEFAULTLIB:"libcd" /NODEFAULTLIB:"libci" /MANIFEST
/ManifestFile:".\Debug\WinGFApp.exe.intermediate.manifest" /ALLOWISOLATION
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:".\Debug/CFFTInstrD.pdb"
/SUBSYSTEM:WINDOWS
/PGD:"C:\WorkSpaces\WorkSpace_CFFT_II_i18n\CFFT_i18n_MBCS\CFFT\Instructor\Debug\WinGFApp.pg
d" /TLBID:1 /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:QUEUE
This is the compiler command line:
/I"." /I"..\Instructor\csw" /I"..\Instructor\CFFTInstr" /I"..\Student\common"
/I"..\Student\Messaging" /I"..\Student\geotrans" /I"..\SerialTcim" /I"..\AudioServer"
/I"..\NetworkUIDM\UIDM_Include" /I"..\NetworkUIDM\UIDM_JVMF" /I"..\NetworkUIDM"
/I"..\Instructor\cas" /I"..\Jvmf" /I"..\Instructor\JvmfGui" /I"..\Instructor\JvmfCff"
/I"..\NLOS" /I"C:\Program Files (x86)\Microsoft DirectX SDK (March 2009)\Include" /Zi
/nologo /W3 /WX- /Od /Oy- /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "NO_MSGS" /D
"INSTRUCTOR" /D "_CRT_SECURE_NO_DEPRECATE" /D "_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES"
/D "_CRT_NONSTDC_NO_DEPRECATE" /D "_VC80_UPGRADE=0x0600" /D "_MBCS" /Gm- /EHsc /RTC1
/MTd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Yu"stdafx.h" /Fp".\Debug/WinGFApp.pch"
/Fa".\Debug/" /Fo".\Debug/" /Fd".\Debug/" /FR".\Debug\" /Gd /analyze-/errorReport:queue
When I open the .vcxproj file in np++ and search for MultiLang.lib it only appears as a dependency in the release build, while in the debug build settings MultiLangD.lib is listed. This is the debug settings ItemDefinitionGroup node from the .vcxproj file:
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<Midl>
<PreprocessorDefinitions>_DEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<MkTypLibCompatible>true</MkTypLibCompatible>
<SuppressStartupBanner>true</SuppressStartupBanner>
<TargetEnvironment>Win32</TargetEnvironment>
<TypeLibraryName>.\Debug/WinGFApp.tlb</TypeLibraryName>
<HeaderFileName>
</HeaderFileName>
</Midl>
<ClCompile>
<Optimization>Disabled</Optimization>
<AdditionalIncludeDirectories>.;..\Instructor\csw;..\Instructor\CFFTInstr;..\Student\common;..\Student\Messaging;..\Student\geotrans;..\SerialTcim;..\AudioServer;..\NetworkUIDM\UIDM_Include;..\NetworkUIDM\UIDM_JVMF;..\NetworkUIDM;..\Instructor\cas;..\Jvmf;..\Instructor\JvmfGui;..\Instructor\JvmfCff;..\NLOS;C:\Program Files %28x86%29\Microsoft DirectX SDK %28March 2009%29\Include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
<PreprocessorDefinitions>WIN32;_DEBUG;_WINDOWS;NO_MSGS;INSTRUCTOR;_CRT_SECURE_NO_DEPRECATE;_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES;_CRT_NONSTDC_NO_DEPRECATE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<BasicRuntimeChecks>EnableFastChecks</BasicRuntimeChecks>
<RuntimeLibrary>MultiThreadedDebug</RuntimeLibrary>
<PrecompiledHeader>Use</PrecompiledHeader>
<PrecompiledHeaderFile>stdafx.h</PrecompiledHeaderFile>
<PrecompiledHeaderOutputFile>.\Debug/WinGFApp.pch</PrecompiledHeaderOutputFile>
<AssemblerListingLocation>.\Debug/</AssemblerListingLocation>
<ObjectFileName>.\Debug/</ObjectFileName>
<ProgramDataBaseFileName>.\Debug/</ProgramDataBaseFileName>
<BrowseInformation>true</BrowseInformation>
<WarningLevel>Level3</WarningLevel>
<SuppressStartupBanner>true</SuppressStartupBanner>
<DebugInformationFormat>ProgramDatabase</DebugInformationFormat>
</ClCompile>
<ResourceCompile>
<PreprocessorDefinitions>_DEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<Culture>0x0409</Culture>
</ResourceCompile>
<Link>
<AdditionalDependencies>MultiLangD.lib;datastored.lib;shlwapi.lib;ws2_32.lib;MdxReadd.lib;winmm.lib;dxguid.lib;dxerr9.lib;dinput8.lib;Messagingd.lib;dtccd.lib;Version.lib;SerialTCIMD.lib;geosrvdll.lib;NetworkUIDMD.lib;amp2.lib;idmmib.lib;vmfr2.lib;d3dx9.lib;comsuppwd.lib;vmf_net_db.lib;jvmfd.lib;%(AdditionalDependencies)</AdditionalDependencies>
<SuppressStartupBanner>true</SuppressStartupBanner>
<AdditionalLibraryDirectories>..\Lib;..\Student\lib;C:\Program Files %28x86%29\Microsoft DirectX SDK %28March 2009%29\Lib\x86;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
<IgnoreSpecificDefaultLibraries>libc;libcd;libci;%(IgnoreSpecificDefaultLibraries)</IgnoreSpecificDefaultLibraries>
<GenerateDebugInformation>true</GenerateDebugInformation>
<ProgramDatabaseFile>.\Debug/CFFTInstrD.pdb</ProgramDatabaseFile>
<SubSystem>Windows</SubSystem>
<TargetMachine>MachineX86</TargetMachine>
</Link>
<Bscmake>
<SuppressStartupBanner>true</SuppressStartupBanner>
<OutputFile>Debug/CFFTInstrD.bsc</OutputFile>
</Bscmake>
<PostBuildEvent>
<Message>Copy Executable</Message>
<Command>if not exist ..\exec mkdir ..\exec
copy debug\WinGFApp.exe ..\exec\CFFTInstrD.exe
</Command>
</PostBuildEvent>
<ProjectReference />
<ProjectReference>
<UseLibraryDependencyInputs>true</UseLibraryDependencyInputs>
<LinkLibraryDependencies>false</LinkLibraryDependencies>
</ProjectReference>
</ItemDefinitionGroup>
Unfortunately, all the executables and dlls generated are copied to a single directory as post build events, so I have to follow the "append D" naming convention to avoid overwriting artifacts from other builds. I'm not sure why none of the other dll projects in the build have this problem. I am obviously missing something here but cannot figure out what it is. Can someone please enlighten me on what I'm doing wrong and how to accomplish this. Thanks.
EDIT
I forgot to mention that I have also tried adding a reference to the project in Common Properties->Framework and References.
Also, while the compilation is under way I see Automatically linking with MultiLang.lib scroll by.
Ok, I got it working. I removed the reference and set Linker->General->Ignore Import Library to Yes. I left everything else the same and now it compiles and links just fine.
What is a path added in Additional Include Directories relative to? Is it the location of the project (.vcxproj)? Is it the location of the solution (.sln)?
According to my test, the path is relative to the project directory, which is set to current during the project build. I created the project with two source files: test.cpp and dir1\test2.cpp. Both include file test_include.h, which is placed in the parent directory. Additional include directory is: ..\ Build log:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c /I..\ /ZI /nologo /W3 /WX- /Od /Oy- /D WIN32 /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Yu"StdAfx.h" /Fp"Debug\test.pch" /Fo"Debug\\" /Fd"Debug\vc100.pdb" /Gd /TP /analyze- /errorReport:prompt dir1\test2.cpp test.cpp
test.cpp
test2.cpp
As you can see, current directory is the project directory, and files in the command line are: dir1\test2.cpp and test.cpp, both are successfully compiled with the same /I..\ switch.