I'm trying to integrate clang-tidy with cmake, but there are some files that belong to a particular target which I would like to ignore.
Is there any way to make clang-tidy to ignore files under certain directory or whose name matches a certain pattern?
Related
I am trying to maintain an ARM command line (makefile) project using the MSVS 2013 Express IDE, to take advantage of the IDE's advanced code analysis capabilities.
The project consists of dozens of directories, each including a "src" and an "include" directories. In order for Intellisense to "understand" the various tokens, I need to add all those "include" directories to the Additional Include Directories search path.
Is there a way to recursively add all folders of a project's filesystem to the path?
If all you want is decent IntelliSense support and don't actually need the projects to build, then you can add the directories to your project as <ClInclude/> items that contain wildcards, e.g.
<ClInclude Include="path\to\root\*\include\*.h" />
You can add as many of these as you'd like and match whatever patterns you need using *. You'll need to add these to the project file manually (using a text editor); the IDE doesn't fully support items that contain wildcards.
I'm currently trying to make splint available as an external tool in Visual Studio 2010.
It has problems with finding all includes for the file, since it seems that the INCLUDE variable is only set at build time and I haven't found any other possibility to extract the include files in any way.
My question: Would there be any way to extract the IncludeDir field from the current file's project's Properties page, ideally with the VC++'s AdditionalIncludeDirectories?
Note also that AdditionalIncludeDirectories is per file, as it can be changed for individual source files as well as on the project level, and if it contains macros it can evaluate differently for each source file too!
I'm not familiar with driving the MSBuild objects via the API, but that's used by the IDE. Whether that way or by simply running MSBuild.exe, you need to get it to figure out all the properties, conditions, etc. and then tell you the result. If everything is well behaved, you could create a target that also uses the ClCompile item array and emits the %(AdditionalIncludeDirectories) metadata somehow such as writing it to a file or passing it to your other tool somehow. That's what's used to generate the /I parameters to CL, and you can get the same values.
If things are not well behaved in that necessary values are changed during the detailed build process, you would need to get the same prelims done just like the ClCompile target normally does, too. Or just override ClCompile with your own (last definition of a target is used) so it certainly is in the same context.
Either way, there are places where build script files can be automatically included into all projects, so you can add your stuff there or use a command argument (I think) to MSBuild to add another Include.
—John
What configuration do I need to give QMake to generate a vcxproj file where the object files are arranged in a tree like the original code?
I have been searching for quite a while and even scrutinized the source of qmake but to no avail.
So far I tried CONFIG -= flat which only changed the filters, but not the output paths. And object_parallel_to_source which only works with makefiles as far as I can tell.
I need the feature to avoid name clashes of object files having the same name, because their source files have the same name but reside in different folders.
It is definitely possible to avoid this with MSVC by setting the appropriate output path for files in their properties dialog. However, this is tedious and as I am developing a project mainly on Linux and then porting it over to Windows from time to time I have to do the whole procedure over and over again.
Since make knows all dependencies to make a target, it knows (almost) all intermediate artefacts. Is there a make version that can 'rollback', or 'unmake' a target?
(I know it removes targets created by implicit rules)
Most Makefiles provide the clean target, which removes all generated files. Additionally, autoconf-automake systems offer distclean, which also removes the files generated by configure.
These are no automatic targets, however; the makefile generation system gives a list of generated files to make. In general, make doesn't keep track which files it generated, so it can't distinguish between genuine source files (which are dependencies) and intermediate files (which are also dependencies). Even the leaf nodes of the dependency graph can't be used for distinguishment, because stamp files often have no dependencies as well.
In Visual Studio 2010 incremental builds are done using the File Tracker (Microsoft.Build.Utilities.FileTracker). It seems that it is responsible to the creation of these *.1.tlog files on the intermediate directory.
I couldn't find any reference to the syntax of these .tlog files.
They contain a list of paths to files that are read/written while the tracker tracks the execution of some tool, in order to check which files should be compiled in an incremental build. However, these files also contain some special characters such as "^" and "|".
Another thing I noticed was that these files are sometimes edited from Visual Studio targets files. For example, in Microsoft.CppCommon.targets on CustomBuildStep target I found the following line:
<!-- Appended tlog to track custom build events -->
<WriteLinesToFile File="$(IntDir)$(ProjectName).write.1.tlog" Lines="#(CustomBuildStep->'^%(Identity)');#(CustomBuildStep->MetaData('Outputs')->FullPath()->Distinct())"/>
So this probably means that the project file is dependent on the custom build step outputs.
My questions are:
Does anyone know of a reference for the .tlog file syntax?
In which cases is the tracker-log used on Visual studio? I know of the CL and maybe Link tasks that use it, but it seems that Visual Studio IDE itself uses it in order to decide whether to run msbuild at all for a certain project.
Thanks
EDIT
Another hint:
CanonicalTrackedInputFiles Class is document as "the filetracking log interpreter for .read. tracking logs in canonical form or those that have been rooted (^) to make them canonical"
When I have time I'll dig into it a bit more. Perhaps this class and others under Microsoft.Build.Utilities could be used to help us work with tlog files instead of working with the raw text tlog files directly.
See also: CanonicalTrackedOutputFiles Class, FlatTrackingData Class and of course FileTracker Class.
This stuff doesn't seem to be documented anywhere, so I've had to figure this out based on trial and error and by staring at some example targets/xml/props files:
The reason the custom build step writes to the tlog file by hand is that Build|Clean - and probably its command line counterpart - scrapes the tlog files to find which files to delete. It seems to look for all files matching *.write.tlog, or maybe *.1.write.tlog, in the intermediate folder, read the list of file names in each, and delete the files named. So, if the custom build steps knows what its outputs are, it can simply record them in a tlog file, and interact with Build|Clean that way.
(You can try this out yourself - build your project, create some temp files, add your own tlog file to your project's intermediate folder containing the paths to the temp files, then do a Build|Clean. Your temp files will be deleted along with the usual build artefacts.)
In a tlog file, a file with no prefix is the name of an output file. These files are deleted when you do a Build|Clean.
A file with a ^ before it a comment, I think - perhaps obviously, Build|Clean doesn't touch any of these.
As for |, I've only seen it in comment lines, used to separate different file names. I suspect this is just a convention, and not some special syntax, since if you put multiple output files on line, separated by |, Build|Clean doesn't delete them.
The tlog file format is now documented here: https://learn.microsoft.com/en-us/visualstudio/extensibility/visual-cpp-project-extensibility?view=vs-2017#tlog-files
Read .tlog format
Read .tlog files (.read..tlog) contain information about source files and their dependencies.
A caret (^) at the beginning of a line indicates one or more sources. Sources that share the same dependencies are separated by a vertical bar (|).
Dependency files are listed after the sources, each on its own line. All file names are full paths.
The tlog file is generated by the file tracking system in MSBuild. It isn't specific to individual compilers, it can capture any file reference by anything done in the MSBuild process, depending on how it is configured.