[splint-discuss] Speeding up splint. (John Carter)
Brian Quinlan
brian.quinlan at iolfree.ie
Mon Nov 24 11:04:55 PST 2008
On Mon, 2008-11-24 at 08:14 -0500, Tony Castillo wrote:
> Here are a few things:
> Splint is a memory hog. Try adding more RAM.
> Splint is not a compiler. Use splint near the end of your project
> (after things are working).
Splint is a compiler that produces errors rather than object files.
If you wait till the end of your project, you'll get a huge number of
errors; it's better to fix them incrementally as they occur during the
project, rather than in one big bang at the end. When I used splint in
the past, the default target initially had a dependency on the splint
target. However, although we had to remove the dependency (because
splint took so long), we kept the splint target which developers were
required to make before checking in code (but not every single time they
built).
> Try to break up modules (.C files). This works best if you have a
> smaller number of header (.H) files
> With large header files, try to combine modules. Combine all of your
> includes into 1 super header file that is used by all modules. This way
> splint only has to parse them once. This is the instance where more RAM
> may be useful.
Be very careful about creating undesired coupling between unrelated
modules because of a tool problem. If all modules include a super
header, then someday, someone will (WILL, not might) use an
inappropriate header because their module can see the header. This will
make it very hard to separate their module from the other modules on
which it has an inappropriate dependency.
> >
> > Currently two thirds of our compilation time is taken up by splint.
> >
> > Is there any way to speed it up?
>
> _______________________________________________
> splint-discuss mailing list
> splint-discuss at mail.cs.virginia.edu
> http://www.cs.virginia.edu/mailman/listinfo/splint-discuss
More information about the splint-discuss
mailing list