Introduction
LintProject is a command line tool intended to make the process of using the PC-Lint code analysis tool (produced by Gimpel software) with Visual C++ projects a little easier and more productive.
PC-Lint analyses C++ code to identify potential problems. By comparison with a C++ compiler such as that provided with Visual C++, it is highly customizable and very thorough, but (understandably) significantly slower. The output it produces is file based, and directed to the console by default, for example:
--- Module: CJFlatHeaderCtrl.cpp
} CJFlatHeaderCtrl.cpp(160): error 1401:
(Warning -- member 'CCJFlatHeaderCtrl::m_bSortAsc'
(line 146, file ..\Include\CJFlatHeaderCtrl.h) not initialized by constructor)
}
CJFlatHeaderCtrl.cpp(166): error 1740:
(Info -- pointer member'CCJFlatHeaderCtrl::m_pParentWnd'
(line 150, file ..\Include\CJFlatHeaderCtrl.h)
not directly freed or zeroed by destructor -- Effective C++ #6) ---
Global Wrap-up error 900: (Note -- Successful completion, 2 messages produced)
Although PC-Lint does a great job of analysing C++ source and header files for potential problems, it is a generic cross-platform tool, and as such, its integration with development environments is limited. For example, when used with Visual C++, PC-Lint can be used to scan the current file for warnings and to direct the results to the Output window, or to scan a list of files defined in a text file.
While this level of integration is just about adequate under some scenarios (for example, when developing new code), it is less than ideal if you want to perform a complete analysis of an entire project or solution. Furthermore, since PC-Lint does not provide any means of generating useful reports on the results, it can be difficult to spot potential problems amongst the mass of results.
If you are working with a large project, these limitations can make using PC-Lint to analyse your code time consuming and difficult, which can potentially be a real disincentive to using this very useful tool on a regular basis. As a result, the quality of your code could well suffer.
LintProject was written to address two of these issues. Unlike PC-Lint, LintProject can read both Visual C++ project and solution files. It can be run against either a complete solution or an individual project:
- When run against a project, it reads the Visual C++ project file (*.dsp, *.vcp, or *.vcproj) and instructs PC-Lint which files to analyse. For each file analysed, the PC-Lint output is captured and recorded in a text file for later analysis.
- When run against a complete solution, LintProject reads the Visual C++ solution file (*.sln, *.vcw, or *.dsw) and recursively analyses the projects it contains.
XML and HTML Reports
Whilst the availability of text files containing the results of the analysis is an essential result of the process, without a means of summarizing their contents and indexing them, the process of interpreting the results is likely to be slow and laborious.
LintProject provides a convenient solution to this problem by writing XML and HTML reports which link to the results files, and indicate how many warnings were found within each implementation file, project, and solution:
Example HTML output
A key design aim of LintProject was to be capable of indicating its process whilst it runs. This is especially important when you consider that a PC-Lint analysis of a large project can take considerable time on some systems. To achieve this aim, the output reports produced by LintProject are automatically regenerated as the analysis progresses. Even better, any supported browser windows* displaying the corresponding results files will automatically refresh as each file is analyzed. This gives immediate feedback on the progress of the analysis, and is proving to be a very useful feature.
* At present, this feature only supports Internet Explorer and derived browsers such as Crazy Browser, Avant browser, etc.
Installation
Installation of LintProject is straightforward. The simplest method is simply to place the executable (LintProject.exe) into the same folder as the PC-Lint executable (lint-nt.exe). If you prefer to locate LintProject.exe elsewhere, the /f switch can be used to tell it where to find the PC-Lint executable.
Using LintProject
LintProject is invoked by a simple command line, for example:
There are several options:
-
/f<FolderName>
Specifies the location of the LintProject executable. This is only required if LintProject is installed in a different folder from the PC-Lint executable.
-
/configfile"<filename>"
Specifies the filename of the Lint indirect file to use. If omitted, std.lnt is assumed.
-
/cfg"<configname>"
Specifies the solution configuration to be analysed.
-
/exclude"<projectname1>,<projectname2>,..."
Specifies the names of projects to exclude from the analysis.
-
/l"<parameters>"
Passes the following parameters to the PC-Lint executable (lint-nt.exe). For example, /l" -background" will instruct PC-Lint to perform analysis at a low priority.
-
/s
Specifies that the HTML output should be automatically opened in a browser window when analysis starts.
-
/?
Display help information.
LintProject runs the PC-Lint executable (lint-nt.exe) on each source file individually, instructing it to redirect its output to a text file which is linked to from the corresponding HTML report. For each file, a command line such as the following is used:
<lint-folder>\lint-nt.exe -i"<lint-folder>" -b -u std.lnt
env-vc6.lnt -i"Debug" <source file> >Lint\<source file>.txt
std.lnt and env-vc6.lnt are standard options files produced by the PC-Lint installation - the latter being specific to Visual C++ 6.0 projects. Although the PC-Lint installation will install only one such file into the PC-Lint installation folder by default, copies of the others are available in the lnt subfolder.
LintProject will use env-vc6.lnt for Visual C++ 5.0 and 6.0 projects (<projectname>.dsp), and env-vc7.lnt for Visual C++ .NET projects (<projectname>.vcproj), so it is a good idea to place the options files you expect to use in the PC-Lint installation folder itself.
Source Code
LintProject is a fairly straightforward command line application built using ATL7. Originally, MFC was used (more for convenience at the time than anything else - the classes used to parse Visual C++ solution and project files were originally taken directly from ResOrg, and originally written under MFC). The dependency on MFC has since been removed.
Parser and utility classes aside, LintProject essentially consists of three classes - CFileLintAnalyser, CProjectLintAnalyser, and CSolutionLintAnalyser - which together control the entire process of analysing the specified project or solution. These classes invoke PC-Lint, index its output, and generate output reports in both XML and HTML formats (the latter by transforming the XML using XSLT stylesheets).
One issue which became apparent early on was that the time taken to analyze a complete project using PC-Lint can be very significant as a consequence of its depth of coverage. To allow the user to see the progress of the analysis, LintProject regenerates its output reports as the analysis progresses. An added dimension is its ability to refresh any browser window on the host PC displaying its reports as the analysis progresses (it's actually quite mesmerizing watching the warning count steadily climb...)
Implementing the browser refresh is one of those techniques which falls into the category of "easy once you know how". It is achieved by enumerating all of the WebBrowser controls open on the local machine using the SHDocVw::IShellWindows interface (see MSDN KB article 176792 - "How To Connect to a Running Instance of Internet Explorer").
For each control retrieved, the URL it is displaying is compared with the canonicalised pathname of the report which has just been updated. If they match, the control is refreshed, causing the updated version of the report to be displayed:
bool RefreshAllOpenBrowserWindows(const CString& sFullPathName)
{
if (sFullPathName.IsEmpty() )
{
return false;
}
DWORD dwLen = _MAX_PATH;
CString sCompareURL;
if (!::InternetCanonicalizeUrl(sFullPathName,
sCompareURL.GetBufferSetLength(_MAX_PATH),
&dwLen,
ICU_BROWSER_MODE) )
{
return false;
}
sCompareURL.Replace( _T("//"), _T("///") );
sCompareURL.Replace( _T('\\'), _T('/') );
sCompareURL.MakeLower();
SHDocVw::IShellWindowsPtr shellws = NULL;
bool bSuccess = true;
try
{
HRESULT hr = shellws.CreateInstance(__uuidof(SHDocVw::ShellWindows));
if (FAILED(hr) )
{
throw hr;
}
long lCount = shellws->GetCount();
for (int i = 0; i < (int)lCount; i++)
{
_variant_t vtIndex( (long)i);
IDispatchPtr idisp = shellws->Item(vtIndex);
if (idisp == NULL)
{
continue;
}
SHDocVw::IWebBrowser2Ptr pWebBrowser = NULL;
hr = idisp->QueryInterface(IID_IWebBrowser2, (LPVOID *)&pWebBrowser);
if (pWebBrowser != NULL)
{
_bstr_t bsURL = pWebBrowser->GetLocationURL();
CString sURL((LPCTSTR)bsURL);
sURL.MakeLower();
if (sURL == sCompareURL)
{
hr = pWebBrowser->Refresh();
if (SUCCEEDED(hr))
{
TRACE("browser refreshed correctly\n");
}
}
}
}
}
catch(...)
{
bSuccess = false;
}
shellws.Release();
return bSuccess;
}
Unfortunately, this technique works only for Internet Explorer and derived browsers. Similar techniques could, of course, be used with any other browser which offers a COM interface and a method of enumerating open windows at a system level. If anyone knows of comparable interfaces which will work for Mozilla, Firefox, and Opera, we would be very interested to hear about them.
Finally, despite appearances to the contrary, LintProject is single threaded. Whilst it could have been written to spawn multiple analysis threads (as Visual Lint does), the extra complexity this would cause just did not seem worthwhile, given its original target use of running with an overnight build.
FAQ
Can I Use LintProject on its Own?
No. To use LintProject, you must have a licensed copy of PC-Lint. Please contact Gimpel Software for ordering information for PC-Lint.
Which Platforms does LintProject Support?
LintProject should run on any system supporting Windows 2000 or later. This restriction is solely the result of the use of the Win32 function SHCreateDirectoryEx(); if you need a version of LintProject which runs on Windows 9x, please contact us and we will be happy to prepare a version without this restriction.
Which Versions of Visual C++ is LintProject Compatible With?
LintProject is compatible with projects and solutions for Visual C++ 5.0, 6.0, Visual Studio .NET 2002, 2003, 2005, and 2008, as well as eMbedded Visual C++ 4.0.
Compilation of the LintProject source requires Visual C++ .NET 2003 or later.
What Configuration does LintProject Require?
None. Simply place the executable into the same folder as the PC-Lint executable (lint-nt.exe), and it should work quite happily.
If you prefer to locate LintProject.exe elsewhere, the /f switch can be used to tell it where to find the PC-Lint executable.
Can I Pass my Own Parameters to the PC-Lint Executable?
Yes. You can use the /l switch to pass parameters directly to lint-nt.exe.
I have Windows XP Service Pack 2 Installed, and Some of the Links in the Reports Don't Work
This is a direct result of the "Local Machine Zone Lockdown" policy introduced in Windows XP SP2, which prevents active content (including JavaScript code, which is included in the HTML reports to provide table sorting facilities) from running when HTML pages are accessed locally.
The following articles discuss the lockdown and its implications:
According to the articles we've read on this, it should be possible to circumvent this by adding "The mark of the Web" (in Microsoft terminology) to the generated HTML. Unfortunately, so far, this has proved unreliable or has had unwanted side effects. We will continue to look for a way to circumvent this restriction, but for now, it can be worked around quite simply by either clicking on the Information Bar when the warning appears and selecting the "Allow Blocked Content" option, or checking the "Allow active content to run in files on My Computer" option in the "Advanced" page of Internet Options:
Note that this issue only affects Internet Explorer. Other browsers should be unaffected.
Which Additional System DLLs does LintProject Require, and What Versions?
LintProject requires MSXML2 or later to generate HTML reports. Although it should be installed by default on Windows XP systems, it can be manually installed, if necessary, by installing the XML SDK (supplied with the Platform SDK).
Aside from MSXML, LintProject should not require any additional system DLLs to be installed. Please let us know if you have difficulties using it on your system.
Finally...
The original version of LintProject was written by Anna during her employment at Sonardyne International Limited. We would like to express our gratitude to them (and in particular, Bruce Baker and Richard Baldock) for agreeing to release ownership of the source to us so that we could maintain and further develop it.
LintProject is freeware. You may use it without restriction, provided all copyright notices in the code and stylesheets remain intact. We hope it proves to be as useful to you as it has to us, and we welcome your suggestions for future enhancements and improvements.
For the latest information on LintProject, please visit the Riverblade website.
Version History
Version 1.4.1.13 (January, 2009)
- Modifications to support $(PlatformName) with VS2002 onwards. Our thanks to Alex McCarthy for contributing these changes.
- LintProject now returns an error code of 1 in the event of an error in the command line. Our thanks to Brett Rowbotham for contributing this change.
- The elapsed time value in project reports now shows hours as well as minutes and seconds (preventing an incorrect elapsed time from being reported for projects which take over an hour to analyse). Our thanks to Brett Rowbotham for contributing this change.
- Removed the unused LintProject.h.
- Updated the MSXML import in stdafx.h from msxml2.dll to msxml4.dll and added the
named_guids qualifier.
- Modifications to support $(SolutionDir) and $(ProjectName). Our thanks to Alex McCarthy for contributing these changes.
- Removed a redundant declaration in CFileLintAnalyser.
- Changed LintProject.zip to LintProject_1.4.zip in MakeZip.bat.
Version 1.4.0.10 (July, 2008)
- Removed all MFC dependencies. LintProject now uses ATL 7 directly, and in consequence, the source now requires Visual Studio .NET 2003 or later to compile (project files are supplied for Visual Studio .NET 2003 and Visual Studio 2008, but porting to other versions should be straightforward).
- Converted the build to Unicode.
- Added support for eMbedded Visual C++ 4.0 workspaces and projects.
- Solution and project specific environment variables $(SolutionDir), $(ProjectDir), $(InputDir), and $(ConfigurationName) are now set during analysis. Our thanks to Andrej Pohlmann for contributing the code to implement this feature.
- If a file of the form .options.lnt is found in the project folder, it will now be used in the analysis command line. Our thanks to Andrej Pohlmann for contributing the code to implement this feature.
- Added error checking for solution/project configurations (attempting to analyse an invalid configuration will now cause an error to be generated).
- Visual C++ 6.0 project (*.dsp) files containing only one project configuration are now parsed correctly.
- Added a /exclude parameter to allow specified projects to be excluded from analysis (our thanks to Andrej Pohlmann for contributing the code to implement this).
- Integrated the solution and project file parsers from Visual Lint, along with various utility functions.
- Corrected a potential buffer overflow in the loading of XSL stylesheets (thanks to Mark Ridgwell for identifying this).
- Corrected a bug in the parsing of intermediate file folders within Visual C++ projects.
- Reinstated a missing -u option in the analysis command line.
- Added the application version to generated reports.
- Fixed a potential COM exception in
Utils::RefreshAllOpenBrowserWindows().
- Fixed minor Lint issues.
- The code is now released under the Code Project Open Licence (CPOL) v1.0; file banners have been updated accordingly.
Version 1.3.1.7 (June, 2007)
- Added the /configfile switch to allow the name of the std.lnt file to be specified.
- Incorporated customer requested fixes and corrections.
- Started removing MFC specific code.
- Fixed most outstanding Lint issues.
Version 1.3.0.6 (March, 2006)
- Added support for Visual Studio .NET solution configurations. The solution configuration can now be specified directly, with the corresponding configuration for each project being selected automatically.
- Added the /cfg? parameter to allow the available configurations to be queried at either solution or project level.
CSolutionLintAnalyser and CProjectLintAnalyser now only attempt to refresh browser windows if the /s parameter is specified. This prevents problems when the utility is run as a service.
Version 1.2.4 (March 2005)
CSolutionLintAnalyser::Analyse() and CProjectLintAnalyser::Analyse() now use SHCreateDirectoryEx() instead of mkdir() to create folders for analysis results so that recursive folders are automatically created. Note: this function requires Windows 2000 or later.- Fix to UNC path checking suggested on the LintProject CodeProject forum.
- Improved handling of relative pathnames. Analysis and source files no longer need to reside on the same logical drive.
- Added support for passing parameters directly to lint-nt.exe via a new command line option (/l"<params>").
- If a warning count of 255 is returned from lint-nt.exe,
CFileLintAnalyser::Analyse() will now parse the results file to try to retrieve the true warning count.
- Re-implemented the
FileExists() helper function.
- Added solution to source code control.
- Modifications to allow operation on systems where PC-Lint is installed in a pathname containing spaces (e.g., C:\Program Files\Lint).
Version 1.2.2 (October, 2004)
LintProject version 1.2.2 released to CodeProject.
|
|
 |
 | Error 89: Argument or option too long
weinerschizel | 8:46 28 Jan '10 |
|
|
Fantastic program !!!!!
I only have one small problem. I've run into this with lint a few times before. When working with a large project that has a lot of include directories, they have to be split onto multiple lines.
It works if each include folder is a new argument to lint...
Thanks! I'll look through the source and see if I cannot figure this out.
|
|
|
|
|
|
|
I've not come across error 89 before, but its definition in the PC-lint manual is as follows:
89 Argument or option too long ('String') -- The length of an
option (shown in String) exceeds an internal limit. Please try
to decompose the option into something smaller. At this writing
the limit is 610 characters.
Do you have any idea which line in the configuration is causing this error? You should be aware that if it is originating in aproject.lnt file, those files are generated by PC-lint directly so you may not be able to do a great deal about it with this particular tool. That said, the Pro version of LintProject shouldn't suffer from this limitation as it writes such files directly.
Please feel free to privmail me directly and I'll do what I can to assist.
Anna  Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
| Unable to open header file
emretezel | 9:30 1 Dec '09 |
|
|
Hi,
I am trying to use the latest version of LintProject to run PC-Lint on my solution. For many files it is unable to load the include file. For example
error 322: (Error -- Unable to open include file '
Is this a known issue.
|
|
|
|
|
|
|
there are many potential causes for an error 322. It could be that your std.lnt file does not contain the correct global include paths, or that PC-lint (which is used to convert the contents of your project files to project.lnt files containing preprocessor definition and additional include folder directives) was unable to interpret one or more of the project files in your solution. Such issues are usually surmountable, but they can require a little detective work.
If you could send me more information I may be able to troubleshoot it for you, but I'll need more detailed information in order to do so. Please feel free to privmail me with any information you think may be useful, and we'll take it from there.
Anna Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
| VC2005 Support
myhfut | 18:58 28 Apr '09 |
|
|
The tool is very good!
If somebody want this tool to support the vc2005,just modified FileLintAnalyser.cpp Line 333 to
"
const CString sFrameworkOptionsFile = IsVSDotNetProject() ? _T("env-vc8.lnt") : _T("env-vc6.lnt");
"
and download the xml4.dll to compile it.
|
|
|
|
|
|
|
env-vc6.lnt, env-vc7.lnt, env-vc8.lnt and env-vc9.lnt are functionally identical - so in actual fact it doesn't matter which one you use. 
|
|
|
|
|
|
|
This is also so, for Visual Studio 2008
|
|
|
|
|
| May be interesting... Installation of PC-Lint
Karpov Andrey | 8:55 7 Dec '07 |
|
|
|
|
|
|
| Fix for sRelativePath workspace paths
NoXQS | 22:18 3 Jul '07 |
|
|
If lintproject doesn't seem to work with your solution files, you can modify CWorkspaceFileBuffer::GetPathName accordingly:
CString CWorkspaceFileBuffer::GetPathName(const CString& sRelativePath) const
{
CString sPathName;
if (sRelativePath.IsEmpty())
{
CSplitPath path(m_sFileName);
sPathName = ::CombinePath(path.GetDrive() + path.GetDirectory(), sRelativePath);
}
else
{
sPathName=sRelativePath;
}
return sPathName;
}
That worked for me.
Thanks,
Morgan
|
|
|
|
|
| Fix for more than 255 errors
NoXQS | 17:24 3 Jul '07 |
|
|
Hi,
Not sure whether my lint version is not the same as the one used in this article, but my lint generated a slightly different message
FileLintAnalyser.cpp/348:
CString sDummy=sLine;
sDummy.MakeLower();
if ( (sDummy.Find( _T("error 900:") ) >= 0) || (sDummy.Find( _T("note 900:") ) >= 0) )
{
CString sCount = ::After(sLine, _T("completion") );
sCount.TrimLeft( _T(" ,") );
m_nWarningCount = _ttoi(sCount);
}
delete sDummy;
That should do the trick. Now lintproject should report with lint 8.00p more than 255 errors/warnings.
Morgan Heijdemann
|
|
|
|
|
| Fix for error 89: Argument or option too long ('String')
NoXQS | 16:57 3 Jul '07 |
|
|
Hi,
First thanks for this great tool. Makes life a lot easier. However, our projects are rather big and lint shoots itself in the foot first not wanting to process the vcproj files and then when you do add (mulitple) +linebuf it is generating lines of options that exceed the max length!
So we have to do some post processing to 'help' lint .
I think this might be addressed before, but hasn't gone live yet.
Change
FileLintAnalyser.cpp(300): sParams.Format( _T("-i\"%s\" -b %s %s %s --u \"%s\" \"%s\" \"%s\" >\"%s\""),
FileLintAnalyser.cpp(314): sParams.Format( _T("-i\"%s\" -b %s -u \"%s\" %s %s \"%s\" >\"%s\""),
ProjectLintAnalyser.cpp(372): sParams.Format( _T("+linebuf %s -i\"%s\" %s \"%s\" >\"%s\""),
to
FileLintAnalyser.cpp(300): sParams.Format( _T("+linebuf +linebuf +macros -i\"%s\" -b %s %s %s --u \"%s\" \"%s\" \"%s\" >\"%s\""),
FileLintAnalyser.cpp(314): sParams.Format( _T("+linebuf +linebuf +macros -i\"%s\" -b %s -u \"%s\" %s %s \"%s\" >\"%s\""),
ProjectLintAnalyser.cpp(372): sParams.Format( _T("+linebuf +linebuf +macros %s -i\"%s\" %s \"%s\" >\"%s\""),
That still leaves (in my case) the -i lines in the .lnt file too long for lint to parse, so we have to split them before writing them to .lnt:
Error 89: Argument or option too long ('String') -- The length of an
option (shown in String) exceeds an internal limit. Please try
to decompose the option into something smaller. At this writing
the limit is 610 characters.
Add at PrintLintAnalyser.cpp/386:
CString sTmpLnk=sLintOptionsFileName+".tmp";
rename(sLintOptionsFileName, sTmpLnk);
FILE *in, *out;
if ((in = fopen(sTmpLnk, "rt")) == NULL)
{
fprintf(stderr, "Cannot open input file.\n");
return 1;
}
if ((out = fopen(sLintOptionsFileName, "wt")) == NULL)
{
fprintf(stderr, "Cannot open output file.\n");
return 1;
}
string sLine;
char cLine[5000];
while (!feof(in))
{
fgets(cLine,5000,in);
sLine=cLine;
if(sLine.find("-i\"",0) != string::npos)
{
int i = sLine.find("; ",0);
while (i != string::npos )
{
sLine.replace(i,2,"\"\n-i\"");
i = sLine.find("; ",i+2);
}
}
fprintf(out,"%s",sLine.c_str());
}
fclose(in);
fclose(out);
if (remove(sTmpLnk) !=0)
{
fprintf(stderr, "Cannot remove tmp file.\n");
return 1;
}
That should do the trick. Now your lintproject should make lint capable of parsing big vcproj files.
Regards,
Morgan Heijdemann
|
|
|
|
|
 | Bugfix
Gulus | 4:29 30 Oct '06 |
|
|
Noticed that error count in web report is at most 255, even
if correct count i much larger. The reason for that bug is that:
the line in FileLintAnalyzer.cpp should not be:
if (sLine.Find( _T("error 900:") ) >= 0)
but changed to:
if (sLine.Find( _T("Note 900:") ) >= 0)
After that correct count is reported.
=======
Anyhow thank's for this great tool and the advisory source code
Gulus
|
|
|
|
|
| RefreshAllOpenBrowserWindows problem
Peter Miller | 7:10 23 Mar '06 |
|
|
Hi,
Firstly, thanks for the very useful tool.
I was attempting to use LintProject as a scheduled task (whether or not user is logged on, so a desktop session is not likely to be running) and found that:
in RefreshAllOpenBrowserWindows throws. I've simply put a try / catch block round it.
Cheers,
Peter
|
|
|
|
|
| Bug or missing feature?..
rbid | 23:00 14 Feb '06 |
|
|
Hello,
Yesterday, after a long while I re-run the LintProject on a bunch of Visual Studio .Net 2003 project space I have, and the the result was that PC-Lint was feeded with a list of AdditionalIncludeDirectories containing a VisualStudio macro that PC-Lint did not find. (as environment variables).
The reason is that the project file used the macro $(SolutionDir) for pointing to the different adjacent project directories...
Here is a sample of the LintProject generated file under one of the sub-projects:
-D_MBCS -i%SolutionDir%/CommonLib -DWIN32;_WINDOWS;_DEBUG -D_MT;_DEBUG;_DLL +fwc -D_WCHAR_T_DEFINED .\FBGenerator.cpp .\FBGeneratorDlg.cpp .\Impairment.cpp .\ItemDlg.cpp .\stdafx.cpp .\ValueItem.cpp
By defining an environment variable "SolutionDir" that points to the correct location, the
tool will run PC-Lint as required.
In the Visual Studio Project Properties, the "$(SolutionDir)CommonLib" line is used as additional include directories for this project.
Have a nice day.
--- Ricky.
-- Ricky Marek (AKA: rbid)
-- "Things are only impossible until they are not" --- Jean-Luc Picard
My articles
|
|
|
|
|
|
|
Hi Ricky,
That's a new one on me! The project.lnt files themselves are generated directly by PC-Lint itself, so this would seem to be a Visual C++/PC-Lint "feature" rather than something we can do much about.
Although an add-in such as Visual Lint running within the IDE can easily expand such environment variables using the VCProjectEngineLibrary interfaces, those facilities just aren't available to external tools. If we did we would have to guess which ones to support, and try to replicate their observed behaviour.
The other odd thing is that in the example above I'd expect to see $(SolutionDir) rather than %SolutionDir%, since the former is the way Visual Studio encodes its internal environment strings. Live and learn, I guess!
By the way, we have a new development version (1.3.0.6) of LintProject almost ready, which supports solution configurations (a glaring omission in current versions). It should be released once our next internal Visual Lint release has completed, which should hopefully happen on Tuesday.
Anna
Currently working mostly on: Visual Lint 
Anna's Place | Tears and Laughter
"Be yourself - not what others think you should be"
- Marcia Graesch
"Anna's just a sexy-looking lesbian tart"
- A friend, trying to wind me up. It didn't work.
|
|
|
|
|
| MFC71.DLL Problem
Gerry Murphy | 6:44 20 Jan '06 |
|
|
Program fails to run with the following error message:
"This application has failed to start because MFC71.DLL was not found. Re-installing the application may fix this problem."
Don't have this DLL on the machine I'm using, nor do I wish to install it (not my machine).
Is there anything you can do, e.g. static linking?
This executable is supposed to work with earlier versions of Visual C++, but cannot be easily compiled with those tools.
Gerry Murphy
|
|
|
|
|
|
|
HI Gerry,
It should already be statically linked, but looking at the code for this version it looks like that option didn't make it into the release build. 
If you grab the latest development version (1.3.0.5) from http://www.riverblade.co.uk/products/lintproject/index.html[^] you should find that the release build is statically linked correctly. 1.3.0.5 also builds quite happily with VC6 if you don't have access to VS2003. 
Anna
Currently working mostly on: Visual Lint
Anna's Place | Tears and Laughter
"Be yourself - not what others think you should be"
- Marcia Graesch
"Anna's just a sexy-looking lesbian tart"
- A friend, trying to wind me up. It didn't work.
|
|
|
|
|
|
|
Nope,
Still get the exact same error.
Nor can I build it. Too many (106) errors.
Gerry Murphy
|
|
|
|
|
|
|
That's odd. I presume this is the dev version (1.3.0.5) rather than 1.2.4? Also, which version of Visual Studio are you using?
I'll try to take a look at it over the weekend.
Anna
Currently working mostly on: Visual Lint
Anna's Place | Tears and Laughter
"Be yourself - not what others think you should be"
- Marcia Graesch
"Anna's just a sexy-looking lesbian tart"
- A friend, trying to wind me up. It didn't work.
|
|
|
|
|
|
|
Yes, I downloaded 1.3.0.5 from the URL you provided.
I'm running Visual 6.0.
Gerry Murphy
|
|
|
|
|
|
|
OK. Do you have VS6 SP6 installed, together with a recent version of the Platform SDK? (the machine I wrote it on had the Platform SDK for WinXP SP2 installed, but any from 2001 onwards should be OK).
Anna
Currently working mostly on: Visual Lint
Anna's Place | Tears and Laughter
"Be yourself - not what others think you should be"
- Marcia Graesch
"Anna's just a sexy-looking lesbian tart"
- A friend, trying to wind me up. It didn't work.
|
|
|
|
|
| Order of parameters
Uwe Keim | 19:28 24 May '05 |
|
|
I created a Extern Tools-entry in VS.NET with the following fields:
Title: PC-Lint on Solution (.sln)
Command: C:\Program files\Lint\LintProject.exe
Arguments: /s /l" -ic:\MyIncludeFolder1;c:\MyIncludeFolder2" "$(SolutionDir)$(SolutionFileName)" "$(SolutionDir)"
Working directory: C:\Program files\Lint\ I just want to point out that if I would place the /s and /l parameters to LinkProject at the end of the command line, I get errors. So although you stated this in your documentation:
LintProject <SolutionName.sln> <ResultsFolder> [options] ,I think this is more correct:
LintProject [options] <SolutionName.sln> <ResultsFolder> Just wanted to point this out in case someone would fall onto this issue, too
Other suggestions
Some more comments on your great tool:- It would be great if you output the command line that you acatually call line-nt.exe with, so a configuration error of mine (like putting the parameters in the wrong order) would be much easier to spot.
- Your documentation says to put quotes after the
/l parameter. What should I do when the parameters for the lint-nt.exe requires quotes itself, like the -i parameter when passing include folders with spaces?
--
Affordable Windows-based CMS for only 99 €: try www.zeta-producer.com for free!
|
|
|
|
|
|
|
Thanks for the feedbacke Uwe. We've a new version under development at the moment, so your timimg is perfect.
Uwe Keim wrote:
Just wanted to point this out in case someone would fall onto this issue, too
Thanks. I'll check that, and update the help accordingly.
Uwe Keim wrote:
It would be great if you output the command line that you acatually call line-nt.exe with, so a configuration error of mine (like putting the parameters in the wrong order) would be much easier to spot.
That's a brilliant idea! Consider it done.
Uwe Keim wrote:
Your documentation says to put quotes after the /l parameter. What should I do when the parameters for the lint-nt.exe requires quotes itself, like the -i parameter when passing include folders with spaces?
You actually don't need to worry about them, as LintProject includes them automatically. If we do the mod above, you'll be able to see what's going on easily enough.
Anna
Riverblade Ltd - Software Consultancy Services
Anna's Place | Tears and Laughter
"Be yourself - not what others think you should be"
- Marcia Graesch
"Anna's just a sexy-looking lesbian tart"
- A friend, trying to wind me up. It didn't work.
|
|
|
|
|
|
|
Anna-Jayne Metcalfe wrote:
That's a brilliant idea! Consider it done.
Thank you
Anna-Jayne Metcalfe wrote:
You actually don't need to worry about them, as LintProject includes them automatically.
But Lint tells me about missing includes if I omit certain -i folders that I specified in my VS.NET options-"Include folders" dialog.
Maybe you should add all the include/executable/source-folders a user specifies inside the VS.NET option-dialog to lint automatically?
--
Affordable Windows-based CMS for only 99 €: try www.zeta-producer.com for free!
|
|
|
|
|
|
|
Last Updated 29 Jan 2009 |
Advertise |
Privacy |
Terms of Use |
Copyright ©
CodeProject, 1999-2010
