I am using the integrated CODAN static code analysis tool in Eclipse CDT. But i want to add some rules to check naming conventions of my code. How can I create and add that kind of rules to Codan?
To add rules to Codan first of all you have to make modification in Plugin.xml file by adding problem and checker tag.
<checker
class="org.eclipse.cdt.codan.internal.checkers.NamespaceNaming"
id="org.eclipse.cdt.codan.internal.checkers.NamespaceNaming"
name="%checker.name.NamespaceNaming">
<problem
category="org.eclipse.cdt.codan.core.categories.CodeStyle"
defaultEnabled="true"
defaultSeverity="Error"
description="%problem.description.NamespaceNaming"
id="org.eclipse.cdt.codan.internal.checkers.NamespaceNaming"
messagePattern="%problem.messagePattern.NamespaceNaming"
multiple="true"
name="%problem.name.NamespaceNaming">
</problem>
Then in bundle.properties you have to add message and description of your problem. After which you have to create a class in Codan Source code, do what implementation you like to do in it (like you can create a pattern with regex so you can compare your file name with it).
Related
I have a series of standard cpp files and each of these files contain a file-specific #include statement. However, the content of those included files must be populated by a pre-processing tool prior to invoking the standard C++ compiler.
The tricky part is that I want this to be fully integrated into Visual Studio using MSBuild. Therefore, when I bring up Visual Studio's Property Window on a cpp file, I want to see all the standard C++ compiler options and, ideally, some Custom Properties controlling the pre-processor tool. As a OOP analogy, I want my build tool to inherit everything from the standard CL MSBuild Rule, and add some Custom Properties & Build Steps to it.
I have successfully done this through an extremely laborious process of basically creating a Custom MSBuild Rule and Copy/Paste most of the C++ Options into my Custom Rule. Finally, I then pass along the million C++ Options to the standard C++ compiler through the CommandLineTemplate entry in my MSBuild .props file. It's ridiculously complicated and the C++ options don't automatically get updated as I update Visual Studio.
I can find plenty of examples of Custom MSBuild Rules, but I haven't been able to find one where it piggybacks onto an existing one.
Not a lot of love for MSBuild, I take it...
Anyway, after years of going back and forth on that one, I finally found something, soon after I posted my question. The key was to search for "extending" existing Rule which, apparently, I hadn't tried before.
Usually, when you create a Build Customization in VS, you end up with 3 files:
MyCustomBuild.xml:
Contains the Properties & Switches, as shown on the VS's Property Sheet.
MyCustomBuild.props:
Contains default values for those Properties. They can be made conditional through the use of the Condition attribute.
MyCustomBuild.targers:
Contains a line to load up your xml and the Target/Task entries.
So the first part was to extend the existing C/C++ Properties as shown in Visual Studio. I found this link, which finally gave me something to work with:
https://github.com/Microsoft/VSProjectSystem/blob/master/doc/extensibility/extending_rules.md
Here's the xml bit.
<Rule
Name="RuleToExend"
DisplayName="File Properties"
PageTemplate="generic"
Description="File Properties"
OverrideMode="Extend"
xmlns="http://schemas.microsoft.com/build/2009/properties">
<!-- Add new properties, data source, categories, etc -->
</Rule>
Name attribute:
The Name attribute must match the rule being extended. In this case, I wanted to extend the CL rule, so I set that attribute = "CL".
DisplayName attribute:
This is optional. When provided, it will overwrite the tool's name seen on the Property Sheet. In this case, the tool name shown is "C/C++". I can change it to show "My C/C++" by setting this attribute.
PageTemplate attribute:
If this attribute is provided, it must match the overwritten rule's value. In this case, it would be "tool". Just leaving it out seems to work fine. I suspect this could be needed if 2 rules had the same name, but a different template. You could use this to clarify which one you wanted to extend.
Description attribute:
Optional. I don't know where that even shows up within the VS GUI. Maybe it's just for documenting the xml file.
OverrideMode attribute:
This is an important one! It can be set to either "Extend" or "Replace". In my case, I chose "Extend".
xmlns attribute:
Required. Doesn't work properly if not present.
As the link suggest, you can then provide the properties, data source and categories. Keep in mind that categories are usually displayed in the order they appear in the xml file. Since I was extending an existing Rule, my custom categories would all show up after the standard C/C++ categories. Given that my tool is for pre-processing the files, I would have preferred having my custom options at the top of the Property Sheet. But I couldn't find way around that.
Note that you do NOT need the ItemType/FileExtension or ContenType Properties, typically found for custom Rules.
So once I entered all of that, my custom pre-processing options showed up alongside the standard C/C++ properties on the Property Sheet. Note that all these new properties would be attached to the "ClCompile" Item list, with all the other C/C++ properties.
The next step was to update the .props file. I'm not going to get into it since it's pretty much standard when create these custom build Rules. Just know that you need to set them using the "ClCompile" Item, as mentioned above.
The final step was to get the .targets file to do what I wanted.
The first part was to "import" (not really an import entry) the custom Rule through the typical entry:
<ItemGroup>
<PropertyPageSchema Include="$(MSBuildThisFileDirectory)MyCustomBuild.xml" />
</ItemGroup>
Then I needed to pre-process every source file. Ideally, it would have been nicer to pre-process a file and then compile it - one file a time. I could have done this by overwriting the "ClCompile" target within my own .targets file. This Target is defined under the "Microsoft.CppCommon.targets" file (location under "C:\Program Files (x86)" varies, depending on the VS version). I basically could have Cut & Pasted the whole Target into my file, then add my pre-processing task code before the "CL" Task. I also would have needed to convert the Target into a Target Batch, by adding an "Outputs=%(ClCompile.Identity)" attribute to the "ClCompile" Target. Without this, my pre-processing task would have ran on all files before moving on to the "CL" task, bringing me back to square one. Finally, I would have needed to deal with Pre-Compiled Header files, since they need to be compiled first.
All of this was just too much of a pain. So I selected the simpler option of defining a Target which looks like this:
<Target Name="MyPreProcessingTarget"
Condition="'#(ClCompile)' != ''"
Outputs ="%(ClCompile.Identity)"
DependsOnTargets="_SelectedFiles"
BeforeTargets="ClCompile">
There are a number of attributes defined but the most important one is the BeforeTargets="ClCompile" attribute. This is what forces this target to execute before the cpp files are compiled.
I also chose to do a Target Batch processing here [Outputs ="%(ClCompile.Identity)"] because it was just easier to do what I wanted to do, if I assumed to have 1 file being processed at a time, in my Target.
The attribute DependsOnTargets="_SelectedFiles" is used to know if a GUI user has some selected file within VS Solution Explorer. If so, the files will be stored in the #(SelectedFiles) Item List (generated by the "_SelectedFiles" Target). Typically, when selecting specific files within the Solution Explorer and choosing to compile them, VS will forcefully compile them even if they are up-to-date. I wanted to preserve that functionality for the automatically-generated pre-processed include files, and forcefully regenerate them as well, for those selected files. So I added this block:
<ItemGroup Condition="'#(SelectedFiles)' != ''">
<IncFilesToDelete Include="%(ClCompile.Filename)_pp.h"/>
</ItemGroup>
<Delete
Condition="'#(IncFilesToDelete)' != ''"
Files="%(IncFilesToDelete.FullPath)" />
Note that the automatically-generated include files are named SourceFileName_pp.h. By deleting those files, my pre-processing Task will forcefully re-generate them.
Next, I build a new Item list from the "ClCompile" Item list, but with the "_pp.h" versions of the files. I do so with the following code:
<ItemGroup>
<PPIncFiles
Condition="'#(ClCompile)' != '' and '%(ClCompile.ExcludedFromBuild)' != 'true'"
Include="%(ClCompile.Filename)_pp.h" />
</ItemGroup>
The final part is a little uglier.
In order to run my pre-processing exe, I use the standard "Exec" Task. But I obviously only want to run it if the source file is newer than the generated file. I do so by storing the well-known metadata "ModifiedTime" of the source file, and the generated file into a couple of dynamic Properties. But I can't use the ModifiedTime metadata directly, as it's not an comparable value. So I used the following code, which I have found on StackOverflow here:
Comparing DateTime stamps in Msbuild
<PropertyGroup>
<SourceFileDate>$([System.DateTime]::Parse('%(ClCompile.ModifiedTime)').Ticks)</SourceFileDate>
<PPIncFileDate Condition="!Exists(%(PPIncFiles.Identity))">0</PPIncFileDate>
<PPIncFileDate Condition="Exists(%PPIncFiles.Identity))">$([System.DateTime]::Parse('%(PPIncFiles.ModifiedTime)').Ticks)</PPIncFileDate>
</PropertyGroup>
Note that I can store the timestamps in Properties, given that the Item Lists only contain one Item per Target Pass, because of Target Batching.
Finally, I can invoke my pre-processor using the "Exec" Task, as follows:
<Exec
Condition="'#(PPIncFiles)' != '' and $(SourceFileDate) > $(PPIncFileDate)"
Command="pptool.exe [options] %(ClCompile.Identity)" />
Supplying the options was yet, another headache.
Typically, the switches as defined under the xml file are just passed to a "CommandLineTemplate" metadata under the .props file using [OptionName]. This will pass the "Switch" attribute of the Property defined under the xml file. But that implies defining your own TaskName item, made from a TaskFactory, under the .targets file. But in my case, I was just using the existing "Exec" Task, which doesn't know anything about my custom Properties. I didn't know how to retrieve the "Switch" attribute in this case, and what seems to be available is just whatever the "Name" attribute contains. Luckily, a Property has both a Name and a DisplayName. The DisplayName is what the GUI user sees. So I just copied the "Switch" value into the "Name" value, when defining the Properties under the xml file. I could then pass the option to the Exec Task using something like:
<Exec
Condition="'#(PPIncFiles)' != '' and $(SourceFileDate) > $(PPIncFileDate)"
Command="pptool.exe %(ClCompile.Option1) %(ClCompile.Option2)... %(ClCompile.Identity)" />
Where I defined all my Properties as "EnumProperty", with an "EnumValue" having Name="" for disabled options, and other EnumValue having Name="switch" for the others. Not very elegant, but I didn't know a way around this.
Finally, it is recommended that when automatically generating files, the .targets file should also include a way to clean them up when the user Cleans up the Project. That's pretty standard but I'll include it here for convenience.
<PropertyGroup>
<CleanDependsOn>$(CleanDependsOn);PPIncCleanTarget</CleanDependsOn>
</PropertyGroup>
<Target Name="PPIncCleanTarget" Condition ="'#(ClCompile)' != ''">
<ItemGroup>
<PPIncFilesToDelete Include="%(ClCompile.Filename)_pp.h" />
</ItemGroup>
<Delete Files="%(PPIncFilesToDelete.FullPath)" Condition="'#(PPIncFilesToDelete)' != ''"/>
</Target>
I created a custom template file and I can use it from the "File"->"New..." menu option.
But I was expecting to see it also when creating a new scratch file using
"File"->"New Scratch File"
Is this even possible?
(I am using PyCharm 2017.1.2)
I think it's not possible: each time you create a scratch file, it's created from scratch.
Though, what's possible in order to simplify your life, is using Live Templates: you can create your own abbreviation, which can be expanded automatically to some portion of code. There are many examples in Settings -> Editor -> Live Templates so you can use them as an example.
In Doxygen you use reference links: define them separately and then refer to them from within the text.
/**
* This is a documentation. Here I link [std::string] to an external web page.
*
* The next line is the link definition:
*
* [std::string]: http://en.cppreference.com/w/cpp/string/basic_string "std::string documentation"
*/
However it seems that the link definition is seen only within the documentation block. It is not seen even on other documentation blocks on the same page.
I want to define some links once, and then use them everywhere (on different pages).
Is that possible?
Edit (follow-up question)
In order to achieve your aim I think your best bet is to make use of the ALIAS facility.
I have managed to set it up with alias like this:
ALIASES += std_string="std::string "
ALIASES += std_vector="std::vector "
And using it:
#std_string
#std_vector
Basically I have one alias for each link.
Can it be achieved with one alias with parameters? The use would be:
#std_ref std::string
#std_ref std::vector
The problem is that some sort of map is needed between the name (the parameter) and the link:
std::string -> http://en.cppreference.com/w/cpp/string/basic_string
std::vector -> http://en.cppreference.com/w/cpp/container/vector
I know it can be done if one parameter would be the different part of the link, like :
#std_ref std::string string/basic_string
#std_ref std::vector container/vector
But this is ugly, error prone and would require to check each time what the link should be.
It's worth noting that what you are currently using is the notation that comes only with Doxygen's support for Markdown - it's not the doxygen method for external links. The original Doxygen method is to insert an HTML link inline...
link text
... but that makes no difference to your original problem.
In order to achieve your aim I think your best bet is to make use of the ALIAS facility. The relevant manual page is here. Using them, you should be able to define an alias like std-string and have it insert the HTML link everywhere you use the alias.
ALIASES are set up in the doxyfile config file (in this section of the manual)
You could set up aliases manually for every C++ keyword, that you want to link to, but the better way to do this is to use the doxygen TAGFILES feature.
A tag file is basically a compact representation of the entities found in the external sources. Doxygen can both generate and read tag files.
To generate a tag file for your project, simply put the name of the tag file after the GENERATE_TAGFILE option in the configuration file.
To combine the output of one or more external projects with your own project you should specify the name of the tag files after the TAGFILES option in the configuration file.
Doxygen has a whole page dedicated to explaining how to link to external documentation
And cppreference.com has already setup a tag file for you with some basic instructions.
For the impatient:
Download File:cppreference-doxygen-web.tag.xml for linking directly to cppreference.com website.
Add this line to your Doxyfile:
TAGFILES += "location/of/cppreference-doxygen-web.tag.xml=http://en.cppreference.com/w/"
I want an automatically generated include-guard by creating a new C++-class with Eclipse/CDT, but I don't find any way to change the ${include_guard_symbol} attribute.
My wish is an include-guard with a namespace prefix like following:
#ifndef NAMSPACE1_NAMESPACE2_HEADER_HPP
But if I use #ifndef ${namespace_name}_${include_guard_symbol} for this, it will produce:
namepace1::namespace2::_HEADER_HPP
How can I do this?
I had a dig around in the source for CDT, and found an undocumented preference setting you can use to change what is generated by ${include_guard_symbol}. There's no GUI for it either, but if you add the codetemplates.includeGuardGenerationScheme setting to <projectpath>/.settings/org.eclipse.cdt.ui.prefs, you can choose between file name (the default), file path or UUID.
Given the file <projectpath>/src/include/Class.h, the following values give these results:
0 gives an upper-case filename, i.e. CLASS_H_
1 gives a UUID, for example. HC9ABE718_D04E_411C_B5A2_F9FE1D9F9409
2 gives an upper-case file path, that is, SRC_INCLUDE_CLASS_H_
To avoid any doubt, here's the contents of our .settings/org.eclipse.cdt.ui.prefs:
codetemplates.includeGuardGenerationScheme=2
eclipse.preferences.version=1
formatter_settings_version=1
It's obviously not exactly what you're after, but we use 2 to give us an approximation of our namespaces since, generally speaking, our namespaces follow our folder structure.
The relevant code is in these files in the CDT source:
core/org.eclipse.cdt.ui/src/org/eclipse/cdt/ui/PreferenceConstants.java for the constants for each option
core/org.eclipse.cdt.ui/src/org/eclipse/cdt/internal/corext/codemanipulation/StubUtility.java for the generateIncludeGuardSymbol() method that does the work.
It would be really nice to see an extra option added for using the namespace, and a GUI too.
I'm using Eclipse Oxygen (CDT 9.3) and as Eelke described in their comment, there has been a UI setting for this for a while now.
However it only lets you choose from the preset schemes, no namespace or richer customisation options available yet.
Search for 'guard' in the preferences dialog, or navigate to C/C++ > Code Style > Name Style and select Code > Include Guard and then choose from the available guard schemes.
More precisely, I want to know, how one can model annotations into the ecore model definition. So that the generated java code would contain them. (For eg: hibernate persistence tags)
This post on the EMF Forums discusses how to use custom templates for code generation: https://www.eclipse.org/forums/index.php/t/131673/.
In a nutshell, you can dynamically provide different templates for your code generation, making it possible to insert the required annotations. In the forum post, Ed Merks (the EMF lead) suggests two pieces of information to read:
http://wiki.eclipse.org/index.php/EMF-FAQ#What_are_Dynamic_Templates.3F
http://wiki.eclipse.org/index.php/EMF-FAQ#How_do_I_use_Dynamic_Templates.3F
and a small example of how to use them:
The inserts look like this:
<%# include file="Class/getGenFeature.annotations.insert.javajetinc" fail="silent" %>
so under your templates folder you'd create files like this:
<someproject>/templates/model/Class/getGenFeature.annotations.insert.java jetinc
and whatever you put in the file will be inserted on the getter. Likely
you'd include guards like this:
<%if (isImplementation) {%>
#Something
<%}%>
Try to follow the convention of using tabs for the indentation since
these will be converted to the formatting preference of the target project.
Once you can provide your own templates you have two choices:
Add the hibernate tags by default to all your code
Modify the templates to read annotations in the ecore model.
For 2, you will need to define your own annotation source (basically a url), something like https://myproject/emf/hibernate and then add EAnnotations to your EClasses that use your custom url and provide key:value settings (e.g. the hibernate annotation to add). Your custom template can then read the annotations from the EClass, query if your source is used and then used the provided values to add the Java annotations.
The post also mentions the Teneo project, that provides JPA support for EMF. No recent development has been done (apparently), but it can be mature enough to use.
I don't think you can to this out of the box. However, you could look into the parameters of the ".genmodel" file to see if you can tweak how annotations (EAnnotations) are being output to the files. The problem with code generation templates is that they are fixed, but maybe through some option in the genmodel you can control how annotations get written to files.