I am generating VisualStudio C++ project files from a build system.
The compiler options in the XML for the project file are in a different format from the command line options specified for the compiler.
I need to get from command line options for cl.exe to the project file options for the VCCLCompilerTool.
1 - Is anyone aware of an open source script designed to do exactly this?
2 - If one removes all the options from the XML and puts all the command line options into the "AdditionalOptions" attribute, will it filter these or is everything put in there added to the command line verbatim ? will the "AdditionalOptions" overide the defaults if there are options present from in the UI ? ( I havn't written a proxy cl.exe to test what it actually gets in this case :)
Thanks!!!!
One solution could be to use Property Sheets (vsprops). You could generate a vsprops file for every option you intend to use (this is done from the property sheet editor in visual studio). Then in your generated project file reference each property sheet that contains the option(s) you intend to use in the InheritedPropertySheets seciton. We do something similar by grouping various options together into related propery sheets. For example we use the following sets of property sheets:
ARMASM.rules
C++ Standards Compliance.vsprops
Debug Program Database.vsprops
Debug.vsprops
Multi-Threaded Debug Libraries.vsprops
Multi-Threaded Release Libraries.vsprops
Optimize for Size.vsprops
Platform Directory.vsprops
Release.vsprops
Static Library.vsprops
Strictest Warnings.vsprops
Win32.vsprops
WinCE.vsprops
Related
I am using VSCode to debug a C++ project configured and built using CMake tools (extension in VScode).
I have to use below command to trigger the execution:
./cbs_ta -i ifile.yaml -o ofile.yaml
As you can see, there are two command line inputs (-i and file name for input file) (-o and file name for output file). I read that using "args" parameter in launch.json, we can pass command line arguments. So I modified "args" in launch.json as follows:
"args": ["-i", "ifile_1.yaml", "-o", "ofile_1.yaml"],
Unfortunately, I am getting error that
the option '--input' is required but missing
I used CMake Tools extension to configure and build the targets.
Please help.
Edit: I have identified that when I click "debug" menu option in CMake in VSCode, the debug session starts but it does not take into consideration launch.json. I identified it since I kept ```"stopAtEntry": true''' but it did not stop at entry point.
It sounds like you have encountered the confusing 'extra' debug button which the CMake Tools extension places on the toolbar. The C/C++ extension's main debugger, configured via 'launch.json', needs to be invoked using the 'debug' view in the left side panel
(as do other debug extensions such as cortex-debug).
Once a debug configuration has been selected, a debug launch button is added to the status bar. This means that users of the CMake Tools extension will then have two different debug buttons on the status bar, which is confusing to say the least. Presumably in part because of this confusion, the CMake Tools extension has options which can be placed in 'settings.json' to remove the buttons it adds to the status bar, either selectively or all together. This is also a useful way to recover quite a bit of status bar real estate, if you don't often need to use things like the toolchain selector.
To remove all buttons added by CMake Tools:
"cmake.statusbar.visibility": "hidden"
And to selectively remove the debug launch button:
"cmake.statusbar.advanced": {
"debug": {
"visibility": "hidden"
}
}
I would expect most users to prefer the selective option, as things like the build target selector are fairly essential to most use cases.
The underlying issue here is that for some reason the CMake Tools extension does not use the standard extension point for debugging functionality, but instead just places an extra button on the status bar to invoke debugging directly without a configuration entry in 'launch.json'. The CMake Tools extension docs describe this as a 'quick' debug function, which suggests that their reason for this design decision is related to different use cases, although personally I can't really see a clear use case for it. Debugging is by its nature an activity which is highly dependent on configuration, as everything from the choice of actual debug program on down needs to be specified in most cases.
I want a run a build step that looks at a .h file, adds some code based on some external params, and hands the resulting file to the preprocessor.
I see the "Custom Build Step" in the project properties. It seems to need an output file. I just want to forward the results to the preprocessor.
It seems like the custom build step wants to do a 1-time process, not per-file or by file type.
The problem is that I don't know how to send my external executable the file currently being processed (eg, "HelloWorld.cpp"). $(InputName) and %(Filename) are blank and docs say it's deprecated. How do I send the filename to my external executable?
But even if I get that working, I don't want to set this per-file. I want all header files to go through this process.
Any ideas?
I've looked at:
https://msdn.microsoft.com/en-us/library/dd293663.aspx?f=255&MSPPError=-2147217396
https://msdn.microsoft.com/en-us/library/hefydhhy(v=vs.90).aspx
https://msdn.microsoft.com/en-us/library/ff770593(v=vs.140).aspx
working on a debug, x64 config on windows.
First of all, No, you cannot modify a file and pass along the results to the next stage (that I could see). I'd need some sort of Program Transformation System.
So I need an intermediate file. That file has to be added to the project, even if it gets overwritten by your code generator. I can associate c++ header files with a custom build tool, and they will all get called one-by-one in the stage of the build specified in the Custom Build Step. The custom build tool will modify the intermediate file(s), and all is well.
The VS 2015 name for the current file being processed is %(Filename). In older versions it has been $(ProjectName) and $(InputName).
In one cpp-file I use the __DATE__ macro to get the compile-date.
It gives me the date of the last compile of that file. But as the file is not changed very often, the date is old in most cases, sometimes several months.
What I actually want is the date of the last build of the project.
Is there an setting to force VS2010 to rebuild that single cpp-file on every compile of the project?
Regardless of changes in the file?
The only way I found until now is to modify the file or delete the created obj-file by an script before the build, I would prefer an solution inside VS if that is possible.
You could probably add a Pre-Build Step that touch (see this thread) the file?
To add a Pre-Build Step, open your Project Properties, then Configuration Properties > Build Events > Pre-Build Event then add the command line you want to have executed in Command Line.
Following the suggestion from Amitd, apparently you can also touch the file using PowerShell, see this for explanations.
As suggested by Adrian McCarthy in the comments below, deleting the .obj file would be preferable in the context where source control is used and you want to keep the .cpp read-only. Using the "macros" exposed by Visual Studio, deleting them can be made easy:
del $(TargetDir)sourcefile.obj
Quoted from Cheers and hth. - Alf as another way to achieve this
nmake (bundled with Visual Studio and the SDK) option /t does a touch, it was once the conventional way to do this for Windows programmers.
You can add the following pre-build step, were you simply touch the date stamp of the file. The +,, is a special flag to the copy command, telling it to update the timestamp of the file:
copy file.cpp +,,
As suggested by Adrian McCarthy, you can simply delete the object file every time you build the project.
Therefore, create a pre-build event invoking the del command. According to Microsoft, you can use the $(IntDir) macro to refer to the directory wher the object file is stored (you should not use the $(TargetDir) macro).
I had issues with the return code of the command (error MSB3073), therefore I changed the command to always exit with 0.
del $(IntDir)datefile.obj & exit 0
Create this build event in the project configuration, under Configuration Properties / Build Events.
In one cpp-file I use the __DATE__ macro to get the compile-date.
It gives me the date of the last compile of that file. But as the file is not changed very often, the date is old in most cases, sometimes several months.
What I actually want is the date of the last build of the project.
Is there an setting to force VS2010 to rebuild that single cpp-file on every compile of the project?
Regardless of changes in the file?
The only way I found until now is to modify the file or delete the created obj-file by an script before the build, I would prefer an solution inside VS if that is possible.
You could probably add a Pre-Build Step that touch (see this thread) the file?
To add a Pre-Build Step, open your Project Properties, then Configuration Properties > Build Events > Pre-Build Event then add the command line you want to have executed in Command Line.
Following the suggestion from Amitd, apparently you can also touch the file using PowerShell, see this for explanations.
As suggested by Adrian McCarthy in the comments below, deleting the .obj file would be preferable in the context where source control is used and you want to keep the .cpp read-only. Using the "macros" exposed by Visual Studio, deleting them can be made easy:
del $(TargetDir)sourcefile.obj
Quoted from Cheers and hth. - Alf as another way to achieve this
nmake (bundled with Visual Studio and the SDK) option /t does a touch, it was once the conventional way to do this for Windows programmers.
You can add the following pre-build step, were you simply touch the date stamp of the file. The +,, is a special flag to the copy command, telling it to update the timestamp of the file:
copy file.cpp +,,
As suggested by Adrian McCarthy, you can simply delete the object file every time you build the project.
Therefore, create a pre-build event invoking the del command. According to Microsoft, you can use the $(IntDir) macro to refer to the directory wher the object file is stored (you should not use the $(TargetDir) macro).
I had issues with the return code of the command (error MSB3073), therefore I changed the command to always exit with 0.
del $(IntDir)datefile.obj & exit 0
Create this build event in the project configuration, under Configuration Properties / Build Events.
I will be creating a series of projects set up to build COM objects. I attempting to create a property sheet (.vsprops file) which will set up the builds for each project. One of the things I am doing with the properties file is customizing the location and names of the files created by the MIDL compiler. Here's the code I use for this:
<Tool
Name="VCMIDLTool"
TypeLibraryName="$(InputName).tlb"
OutputDirectory="$(RPCDIR)"
HeaderFileName="$(InputName).h"
DLLDataFileName="$(InputName)_dlldata.c"
InterfaceIdentifierFileName="$(InputName)_i.c"
ProxyFileName="$(InputName)_p.c"
/>
RPCDIR is a macro defined before this section of the property file. This works great for compiling the code. When I build my project, these five files are created with the correct names in the location I specified in the RPCDIR macro. My problem is when I try to clean the build. The clean successfully deletes four of the files, but the DLL Data File does not get deleted. I'm especially confused that some are deleted and one is not - I would have thought that either they would all be deleted or none be deleted rather than a split like this.
Does anyone know how I can customize the clean build to correctly delete these files? Optimally any changes I need to make would be in the property sheet so that I can share it with other projects, but if that's not possible then I'd like to at least be able to do it in the project file. Thanks in advance for any help you can offer!
Not your problem, it is a bug in the build system. The dlldata.c file doesn't get deleted using a regular build either. There aren't enough diagnostics available in the msbuild .log files to see what target fumbles this. I'm guessing it has something to do with the <FilePatternsToDelete> item in the Microsoft.CppClean.targets file.
I recommend you report this problem at connect.microsoft.com