Re: Add external tool for Lint software in NBEclipse IDE
Posted: Thu Feb 07, 2013 4:34 pm
Let me clarify; the blog post assumes you are using co-gnu3.lnt. I didn't realize that was obsolete until I started using boost. Since making that post I have switched to co-gcc.lnt. I read the top of the co-gcc.mak file and the gcc-readme.txt. My results weren't much better (if any) than using co-gnu3.lnt but if I want help from gimpel tech support I had to go down this path. Here's the steps I took (if memory serves) I created a .bat file with thisThis ends with an error and leaves size-options.lnt blank. My netburner.lnt file specifies size options for si, sp and sl and I suspect that's what this would do. My best guess is it fails because I'm running Win64 and the generated file co-gcc.mak.temp-generate-size-options will only run under 32 bit. Gimpel wasn't any help with any of this. Did you get a size-options.lnt file? If so can you paste the contents here?
So now my netburner.lnt file specifies co-gcc.lnt and the entire file looks like thisThe only other change I made was to comment out a line in co-gcc.lnt that was causing me problems:The biggest pain in the butt now is that I can't lint any source file that includes any boost library. It just generates tons of noise. The 2nd biggest problem is I tend to use namespace aliases This too, causes lint a ton of headaches, James Widman at Gimpel tech support says they support namespace aliases but didn't really help me figure out why this wasn't working.
While I have advocated for using Gimpel's lint in the past (and I still use it when I can) my opinion has increasingly become that it's a bigger pain than it's worth. Especially when I consider how seamless a tool like ReSharper is to use for C# code. The amount of setup and configuration that goes into lint is ridiculous. As I'm increasingly using more of the boost library, it's becoming less and less useful.
Unfortunately, I don't know of any better alternatives. I have tried CppCheck and while it is very easy to set up and use, it does very minimal checking compared to lint. Still a lot of people would probably pick up an error/optimization or two if they used it regularly (and I just found out there is now an eclipse plug in.) My hope is that CppCheck will get more comprehensive as time goes on.
Code: Select all
make -f co-gcc.mak ^
GCC_BIN="m68k-elf-gcc" ^
GXX_BIN="m68k-elf-g++" ^
CXXFLAGS="-O2 -falign-functions=4 -gdwarf-2 -Wall -Wno-write-strings -c -fmessage-length=0 -fno-exceptions"
So now my netburner.lnt file specifies co-gcc.lnt and the entire file looks like this
Code: Select all
c:\lint\co-gcc.lnt
c:\lint\au-sm123.lnt
-si4 -sp4 -sl4
-iC:\Nburn\Mod5272
-iC:\Nburn\Mod5272\system
-iC:\Nburn\include
-elib(129)
-elib(10)
-elib(19)
+libclass( foreign )
//For Eclipse, we change output format of messages
-"format=LINT %t%(: %f:%l %) %n %m"
-width(0,0)
Code: Select all
//TEG TODO Commented out the next line
//+cpp(.cc,.C) // extensions for C++ that are commonly used in addition
// to the default extensions of .cpp and .cxx
Code: Select all
namespace SL=SyncorLibrary;
While I have advocated for using Gimpel's lint in the past (and I still use it when I can) my opinion has increasingly become that it's a bigger pain than it's worth. Especially when I consider how seamless a tool like ReSharper is to use for C# code. The amount of setup and configuration that goes into lint is ridiculous. As I'm increasingly using more of the boost library, it's becoming less and less useful.
Unfortunately, I don't know of any better alternatives. I have tried CppCheck and while it is very easy to set up and use, it does very minimal checking compared to lint. Still a lot of people would probably pick up an error/optimization or two if they used it regularly (and I just found out there is now an eclipse plug in.) My hope is that CppCheck will get more comprehensive as time goes on.