Visual Lint 220.127.116.11 has been released
|Monday, June 22, 2009
The following changes are included in this version:
- PC-lint analysis results generated without an environment file (i.e. no env-vc*.lnt file) can now be parsed correctly.
- Project indirect (.lnt) files generated by previous versions of Visual Lint will now be automatically re-generated.
- When a lint issue without an associated source line number is displayed in the Analysis Results Display, the line number is now shown as blank rather than 0.
- Added a "Copy | Issue Text Only" command to the Analysis Results Display context menu. This is identical to the existing "Copy" command (now renamed "Copy | Full (with Source File Info)" but omits the source file information.
- Local analysis tasks now only report progress when the scheduler is not busy performing other tasks. This should improve performance on n-core high performance systems with "noisy" codebases.
- Visual Studio automation model interface pointers are now cached in the context of the calling thread. This reduces the use of the Global Interface Table, and hence simplifies thread synchonisation.
- Corrected a bug which was affecting Intel C++ Compiler support in Visual Lint Enterprise Edition.
- Added support for Intel C++ Compiler 11.0 projects, which use a different project file format to previous versions.
- Modified the IncrediBuild version checking code for compatibility with IncrediBuild 3.4.
- Visual C++ 2008 project (.vcproj) files created using the "Create Project from Existing Code" wizard are now parsed correctly. Such project files are created with UTF-8 encoding instead of the usual Windows-1252, and it seems that MSXML does not correctly support loading an XML stream with a UTF-8 byte-order mark from a Unicode string.
- Fixed a bug in the "Delete Analysis Results" menu command in the Solution Explorer.
- If hosted under VS2008 and running on XP, new installations no longer create a linked window frame to contain the Analysis Status, Results and Message Lookup Displays. This avoids a recently identified shutdown crash which appears to be specific to this combination of operating system and development environment.
Posted by Anna at 10:53 | Get Link
LintProject Professional 18.104.22.168 has been released
|Wednesday, June 17, 2009
When I recently blogged about support for non-Microsoft project file formats, I mentioned that we were in the process of adding support for Texas Instruments Code Composer 3.x (.pjt) projects.
I am pleased to announce that this functionality is now available as part of LintProject Pro 22.214.171.124. Other non-MS project file formats (notably Eclipse/CDT and the various CodeGear C++ Builder formats) are now also being looked at, so watch this space.
The full set of changes in this build include:
- Added support for Texas Instruments Code Composer Studio 3.x (.pjt) projects.
- Added skeleton support for Visual Studio 2010 (.vcxproj) projects.
- Added support for Intel C++ Compiler 11.0 projects, which use a different project file format to previous versions [from Visual Lint 126.96.36.199].
- The help screen ('/?' switch) now shows which solution/workspace and project file types are supported.
- Project configuration specified on the command line are now case-independent.
- For loop compliance settings are now read from project files and written to the corresponding project indirect files directly.
- Corrected a bug in the parsing of the /param switch introduced in LintProject Pro 188.8.131.52.
- Improved command line validation and error reporting.
- Added logging of command lines and console output (to CSIDL_COMMON_APPDATA\Riverblade\LintProject Professional).
- Updated the readme file to include newly supported development environments and corrected a typographical error in the licence file.
Posted by Anna at 12:49 | Get Link
Visual Studio 2010 Support for Visual Lint and LintProject Professional
|Tuesday, June 09, 2009
If you follow technical blogs you can't help but have noticed that Visual Studio 2010 has now entered beta. The new IDE is on course for release towards the end of this year (my bet is on November as that's when both Visual Studio 2005 and Visual Studio 2008 shipped).
Community Technical Previews (CTPs) of the new IDE have actually been available for the new IDE for over a year now, so it should come as no surprise that we have actually had limited VS2010 support in the Visual Lint development codebase for quite some time now. As a result, for us the recent release of Visual Studio 2010 Beta 1 has been an opportunity to see what has changed since last time. Beta 1 is actually quite a major change from the last CTP, including (for example) a new MSBuild style Visual C++ project file format (
.vcxproj), a WPF (Windows Presentation Foundation) based editor and multi-monitor support.
The IDE now looks noticeably different to VS2005 and VS2008, and I have to say that my initial impression was not entirely positive (although Beth rather likes it). Whether that impression will last once I've had a chance to use it a bit more, we'll see.
Of more direct concern to us than the UI styling is of course the new project file format and whether the Visual Studio automation interfaces (which we use to interface Visual Lint to the development environment) are working correctly.
Being an MSBuild script, the new
.vcxproj project file format is far more complex than the previous
.vcproj format. Although that is something of a headache for us (Visual C++ project files can be rather intricate, so a new format always results in significant development and testing), it is probably not an issue for most developers. If you have a codebase where you have to maintain project files for multiple versions of Visual Studio and/or make a habit of hand editing project files (as I do sometimes) you may be in for a bit of a shock, however.
We actually wrote a basic parser for
.vcxproj files some time ago (fortunately the format does not appear to have changed hugely since then) so over the next few months we will be gradually enhancing it to support the full range of Visual C++ project file capabilities already present in our existing
.icproj (Intel C++ Compiler project) file parsers. In the meantime, the new parser will become available in LintProject Professional shortly - so LintProject Professional will actually gain full support for Visual Studio 2010 projects before Visual Lint itself.
What does concern us however is that Beta 1 appears to have significant regressions in the Visual Studio automation interfaces - even simple operations such as adding a pane to the Output Window, creating a Toolwindow or retrieving the handle of the top level window seem to be broken. These are quite fundamental operations which third party add-in products such as Visual Lint rely upon to function correctly, so it is rather worrying that we are seeing such regressions. As these interfaces seemed to be working just fine in the last CTP I think I can say with some confidence that the integration of the new WPF based editor is implicated in the regression.
We can only wait to see if Beta 2 will address these issues so that we can carry on integration testing. In the meantime, we are starting to post bugs on Microsoft Connect and waiting for feedback from Microsoft.
Posted by Anna at 11:17 | Get Link
Non-Microsoft Platforms, Visual Lint and LintProject Professional
|Monday, June 08, 2009
Integrating a plug-in product such as Visual Lint into a new development environment is a rather time consuming and difficult operation - even (unfortunately) when the new IDE is just a new version of one we already support (I'm looking at you, Visual Studio 2010!). Even worse, although the big players (notably Visual Studio and Eclipse) have quite comprehensive plug-in models many do not - which effectively makes it impractical for third party vendors to port their tools to those environments.
As a result we have been forced to conclude that in most cases it is not practical for us to develop a Visual Lint plug-in for such development environments. Fortunately, the converse is now (following some recent changes to the way it handles project files) true for LintProject Professional.
Please note that the remainder of this blog post describes functionality introduced in LintProject Professional 184.108.40.206; it is not present in earlier versions.
In fact, adding a new project file format to LintProject Professional is rather easy - in most cases, as we need to do is add a new project file reader implementation and enable it in the build configuration.
As a test, we have just done exactly that for project files for one of the development environments recently requested - namely Texas Instruments Code Composer Studio 3.x. For clarity, I'll refer to this IDE as CC3 for now.
CC3 project (.pjt) files are actually very simple, so this was an ideal test case:
; Code Composer Project File, Version 2.0 (do not modify or remove this line)
["Compiler" Settings: "Debug"]
Options=-g -@"options.txt" -fr"$(Proj_dir)\Debug" -i"projectincsearch" -d"_DEBUG" -d"_HELLO" -u"_UNDEFTHIS" -mv5e --abi=ti_arm9_abi
["Compiler" Settings: "Debug2"]
Options=-g -fr"$(Proj_dir)\Debug2" -d"_DEBUG" -mv5e --abi=ti_arm9_abi
["Compiler" Settings: "Release"]
Options=-o3 -fr"$(Proj_dir)\Release" -mv5e --abi=ti_arm9_abi
["Linker" Settings: "Debug"]
Options=-c -m".\Debug\CC3Test.map" -o".\Debug\CC3Test.out" -w -x
["Linker" Settings: "Debug2"]
Options=-c -m".\Debug2\CC3Test.map" -o".\Debug2\CC3Test.out" -w -x
["Linker" Settings: "Release"]
Options=-c -m".\Release\CC3Test.map" -o".\Release\CC3Test.out" -w -x
["Untitled2.c" Settings: "Debug"]
Once we had written a suitable project file reader implementation, LintProject professional was able to generate the following project indirect file, which it then used to analyse the sample project:
// Generated by LintProject Professional 220.127.116.11a from file: C:\Data\Projects\Applications\LintProjectPro\Test Solutions\CCStudio\CC3Test\CC3Test.pjt
-D_DEBUG;_HELLO; // PreprocessorDefinitions = "_DEBUG;_HELLO;"
// AdditionalIncludeDirectories = ""optionsfolder";"projectincsearch" ;"
Untitled2.c // RelativePath = "Untitled2.c"
Although I have no doubt that we will have to "tweak" the contents of the project.lnt file output as a result of user feedback, this is a pretty good starting point from what I can see.
Ironically, CC3 workspace (.wks) files are binary (they actually look like serialised MFC CArchive files) so they are far as tricky to parse as the project files are easy. hence, for the time being we are only adding support for CC3 project files, and not the workspace files themselves.
While we are in the LintProject Professional code we have also made a minor change to the help screen, which now lists the solution/workspace and project file types supported:
Incidentally, I should clarify that we are certainly not ruling out a Visual Lint plug-in for Eclipse (or any other mainstream IDE with a comprehensive plug-in model for that matter) - it is simply that the steps needed to get support into LintProject Professional are a necessary precursor for a full integration anyway, and this way we also can deliver something useful up front.
Posted by Anna at 15:49 | Get Link