I'm trying to get the compilation args for each compilation unit so I can create the "compilation_commands.json" for my vcxproj that can be used with clang's libTooling.
The libTooling tutorial suggests using a CompilationDatabase to provide the compilation args for all the cpp files in a project. The tutorial shows that CMake can generate the compilation_commands.json for CMake based projects.
Since clang can be put into "MSVC mode" via clang.exe --driver-mode=cl or clang-cl.exe my thought was if I could get the compilation args for each cpp file in my VS2012 project I can create the compilation_commands.json for a vcxproj.
However I'm having trouble finding APIs in the VS2012 SDK that walks a vcxproj and retrieves the compilation args for each compilation unit. Can someone point me towards the right APIs?
I know this is really old, but the question is still relevant, so for those still looking for an answer, I managed to finally do this recently using this little VS extension.
Just install it and a new 'Sourcetrail' menu will appear, with a 'Create Compilation Database' entry (I found Intellisense needs to be enabled for it to be clickable). That will let you customize what to include and generate a compile_commands.json that you can use with other clang-based tools, etc.
It is a DIY job. The VS IDE projects have properties for each .cpp file. By selecting a .cpp, then right-click -> Properties -> Config properties -> C/C++ -> Command-Line you have the options required to compile that specific file. The 64 dollar question is how to do it for every file in the project / solution. The answer is not trivial, but it is doable. At least I did it on VS 2010 and I'm pretty sure it works on VS 2012/3
The secret lies with what is called VCEngine. It is a tool that evaluates all the properties or the files in the project. So the real problem is how to evaluate the property "Command Line" for each file. You need to iterate through all the .cpp files and call VCProject's Evaluate method for the "Command Line" property.
The simplest way I think you can do it is to write a plugin for the VS IDE and thus gain access to the VCEngine instance. There are plenty of examples of how to do that. Be aware that the VCEngine is version dependent.
Anywhay, for projects/solutions with thousands of .cpp files, you need to automate the compilation database creation.
When I'll have time I will put the solution on github
You may be interested in reading this
compile_commands.json for Windows/MSVC
You can try to parse the CL.command.* files in the intermediate directories.
https://gist.github.com/Trass3r/f3fbe6807d28106e917368c33abf45d4
Related
i want to move from using CMake to Premake for my current project, but im usig vim and the YCM plugin which is really great for making my setup like an IDE. However, the plugin needs compilation flags file which is produced when running CMake. Is there something for Premake to generate a file like that as well?
Premake does not do this in its current state (alpha 13). If you have some insights as to what is necessary for getting it to work, the best thing to do would be to submit a ticket in the issue tracker.
I'm afraid, if your new build system does not generate that compilation flags file (yet), you'll need to maintain your own (hand-crafted) one. You can find an example at https://github.com/Valloric/ycmd/blob/0e999dbee209ea79a522259816ce3a68b7d6cddc/examples/.ycm_extra_conf.py.
I would advice to have (at least) one per project rather than one generic one in your $HOME.
Although I have to admit, that it would be beneficial to get it created and in sync with the actual build system, I don't find it too troublesome to maintain it manually. At the end of the day it only contains the C++ standard you want to use, a set of preprocessor symbols and a set of both system and user include directories.
I have a library which includes samples of how to use the library along with unit tests.
I'm trying to create custom VS2012 solutions that will be in the deployment.
Depending on input given when initiating the deployment, I want to be able to create a solution - e.g. Samples.sln - which includes projects specified in the input file.
Example:
//inputfile1.txt
ProjectA
ProjectB
I run an MSBuild xml file or an F# script (or anything that can do this) and I get a Samples directory with a Samples.sln containing ProjectA, ProjectA.Tests, ProjectB, ProjectB.Tests
A similar thing would happen if I gave an input file with ProjectX & Project7... etc.
With MSBuild, I've figured out how to read the file input, copy project folders to a new folder, and do some other things I would need for this whole process but I can't figure out how to create and customize a solution. I'm not sure this is even possible with MSBuild - I think I can only alter an already existing solution (but I've had trouble doing this as well).
I figure I have these options:
A. Add all projects to a Samples solution, then use msbuild to turn them on or off
or
B. There exists some other way (not using msbuild) to do this whole process
Is msbuild even capable of A?
You should understand that MsBuild mainly is a build platform. It also happens to be able to read and write file etc but that's not it's core business. So while you can generate solution files for it, it's going to be pretty hard using just MsBuild as it's simply not meant to be able to do things like that directly.
Here's an option C: if you open an sln in the text editor you'll see the structure is quite straigtforward: for every project there's a Project ... EndProject. You could generate these strings in the proper format (that is, genareate guid, figure out relative path to solution, get project name from path, ...) in an MsBuild target, put all of them in an ItemGroup then write it to a solution files using WriteLinesToFile. Perfectly possible, but a lot of work and I wouldn't recommend it.
For your option A, that's even harder: to include/exclude projects from a build, VisualStudio uses the .suo files and those are in some binary proprietary format which I have no idea how to generate.
That leaves you with option B which is basically option C but without reinventing the wheel: find a tool that can generate solution files for selected projets and have MsBuild invoke it useing Exec. There are probably a bunch of tools that can do this, but here's an example using the first usable one I found on the internet called SolutionMaker. Suppose your projects are in directory Foo, you'd use it like this:
<Exec Command="SolutionMaker /s Foo/foo.sln /p Foo /v 2012"/>
since the corresponding command line options are
/s <solution>: Solution file path
/p <path>: project root path
/v <fileVersion>: New solution file will be generated in the specified format.
valid versions: 2008, 2010, 2012.
I am using F# in Visual Studio 2012 and this may seem like a dumb question but I cannot figure out how to specify include directories, specifically for binaries. I see how to do it for F# interactive using the #I directive and it works there, but the #I option is not available in the non-interactive form. The compiler error message says to use the -I compiler option. I have looked under Project Properties, where the only subsections visible are Application, Build, Build Events, Debug, and Reference Paths none of which provides any obivous way to specify an include directory path. The help system isnt much help as it seems to reference sections that are unavailable.
Well i still have the problem with VS12 but at least i have a workaround, by calling the compiler from the command line. You have to use the -r option to specify the location of the dll:
fsc -r:<complete path to dll> <fname>
However when i try the corresponding step in VS (by trying to set one of the Reference Paths) it says there are no items found in the DLL folder. So perhaps someone familiar with CS can help out
Error 2 error LNK1104: cannot open file 'OgreMain_d.lib' C:\Users\Owner\Documents\Code\C++\Test\ogrevcpp\ogrevcpp\LINK ogrevcpp
This is the error I get when trying to build an Ogre3D application (with steps followed from here).
I've followed everything to the T, yet I still get the error. It honestly shouldn't be happening. I've also followed everything from here.
Edit
What's happening is there are two different files, one is meant for release, the other is meant for debug. I need the one for debug mode to compile properly (which is OgreMain_d.lib).
Update
I figured out what the problem was - I was using the incorrect binaries; there was a few releases which were meant for Visual C++, and one which was meant for MinGW, along with a few other compilers. My apologies.
You need to check your library paths to make sure that the path where OgreMain_d.lib lives is part of the library path.
I guess the library for Debug mode is not present in the lib folder. Try putting two different libraries folder for each Assembly mode in Visual Studio. Go to ProjectProperties -> Configuration Properties -> Linker -> Additional Library Directories on Right hand. Make sure to check the Configuration Dropdown on the top.
I come from a Java background, and the shop where I currently work refuses to use anything other than MS VC++ to build their legacy project. They don't appear to use any standards for setting up their build environment other than just building it using VS2005 and clicking the compile button.
I was wondering if there was anything closer to what Java had for instance:
A build tool like ANT or Maven
A directory structure that makes sense containing
src - Place for all my source files .c/.cpp/.h
lib - A place for any libraries that might be used in the project (.dll, .lib)
dist - A place for the output executable/distribution of the project
resources - A place for any images/sounds/text files that might be included in the project.
build.xml - Some sort of a build file (my guess would be something like ./configure or MAKEFILE)
Or am I asking too much from a C++ build environment? Is it just always as chaotic as the people in my shop make it out to be? I really have a hard time believing that considering the success of so many C++ projects on the internet.
It sounds like you have good intentions - coming form a non MSVC world I can see your points.
If I were in y our shoes I would definitely make a command line/automated build/build server.
You can use MSBuild for this - and hudson has a plugin for this. I usually have a "Build" directory near the root of the projects that contains scripts/etc that will call the appropriate MSBuild/.sln files.
The "makefiles" for Visual Studio are .sln and .vcproj files. You can call those with msbuild from the command line. You can also export a makefile (I think that is still an option) from within the IDE that you can run. I don;t recommend going that route though other than trying it out and seeing what is output - since that is what you are familiar with.
Both the vcproj and sln files are human readable - go through them - it will give you some useful information.
I would also agree that having a distributon directory is good - for building an installer/etc after the build. Copy all the needed binaries there - either in postbuild steps or in another script/etc.
Let us know what you end up doing.
I have one other piece of advice:
UPGRADE to VC/Dev studio 2008 or 2010. ASAP
MSVC does not impose any directory structure on you. There are some defaults, as mentioned above for the Debug and Release directories, for example, but even these can be overridden on a per-project basis. Use whatever directory structure makes sense to you.
Visual Studio does provide command line support if you don't want to use the IDE. See This MSDN Article for more information.
You can setup a proper build environment using Visual Studio (and for solutions with more than one project, you should), and there are a number of environment variables to use in the project configuration to set so that output files and intermediate files go to different folders than those defined by default.
In our large VS solution, we use e.g. obj/$(ProjectName)/$(ConfigurationName) as intermediate directory and bin/$(ConfigurationName) as output directory in all sub-projects.
All these things must be enforced by the user, and it seems that no single recommendation/best practice has evolved.
The standardized stuff:
The build tool: Visual Studio (doesn't need an extra product)
Build file: *.sln / *.vcproj (*.vbproj for Visual Basic, etc)
Directory structure: "Debug" and "Release" directories for the output binaries.
The rest isn't so much "chaotic" as "doesn't really matter". "Chaotic" suggests that it changes all the time, but in reality you just pick one for a project and stick with it. Companies may have internal standards across projects. It just doesn't matter enough to bother standardizing across companies. C++ is a complex language anyway; anyone with sufficient IQ to read C++ can deal with reasonable variation. The difference between \lib\ and \Library\ won't stop them.