lint for D

[Yigal Chripun]

Markus Koskimies wrote:
> On Thu, 10 Jul 2008 15:37:16 +0900, Bill Baxter wrote:
> 
>> Markus Koskimies wrote:
>>> On Thu, 10 Jul 2008 01:42:17 +0100, Bruce Adams wrote:
>>
>>> I must disagree with this. Just like D has integrated doc generator, I
>>> would like to see it bundled with a tool doing all kinds of static
>>> checks also; it need not to be integral inside, but released with
>>> compiler and automatically invoked by the compiler. The reason for this
>>> hope is very simple - it would make things simple from developers point
>>> of view. Just write:
>>>
>>> 	dmd <all my D files>
>>>
>>> ...And it would not only compile the executable (possible recognizing
>>> which files need to be recompiled, normally done by make), but also run
>>> static checker. That's also the reason why I like the "-od" -style
>>> options (telling directories to put things).
>> If the hypothetical lint tool existed, you could just write a script
>> containing:
>>
>>    <split up options>
>>    dmd $options_meant_for_dmd
>>    dlint $options_meant_for_dlint
>>
>> There's just a bit of work to do there to filter out the options and
>> split them into separate variables.  But if someone can write a lint
>> tool, they should be able to figure out how to do that.  :-)
> 
> In ideal world that's true. But in practice (my experience with C++ & 
> lint) if the lint-like tool is not a part of the compiler release, you 
> spend a lots of time to configure the lint to understand the compiler 
> options and features.
> 
> But that's just my opinion. I would prefer a compiler release, where:
> 
> 	dmd -w <all the files & options>
> or:
> 	gdc -w <all the options & files>
> 
> ....is alias for:
> 
> 	dlint <all the files & options> \
> 	&& \
> 	dmd/gdc <all the files & options>
> 
> It really does not matter if the lint-like tool is integral part of the 
> compiler, but it would help a lot if the compiler could be instructed 
> first to make static analysis before starting to generate code. Sure it 
> would be great, if the lint and compiler understand the same language 
> (i.e. they share the same parser) and same options.
> 
> It is just the way I normally work; I enable all possible warnings and I 
> would like to get rid of them all.

IMO, the UNIX way is the correct way. I actually prefer to remove the
documentation generation from DMD.
the compiler should only compile code and nothing else.
if you want to do something more complex than just compile a file you
should use a build tool. a build tool is where you want to integrate all
the separate tools together. look at ant for example: you can define an
ant task for compilation, a different task for doc generation, another
to run lint tools, etc... ant itself uses xml files (which is bad IMO)
to define those and is extensible (which is good).
there are build tools that are written as libs in a scripting language
and your "makefile" than just become a regular python script (scons) or
ruby script (rake/rant).
also, build tools like that can be integrated in your IDE. (If i'm not
mistaken eclipse can work with ant projects, so you can use gui for
everything)

just use ant/rake/scons/what ever instead of dmd in your example.
All of those are orders of magnitude better than make and even with that
 you can have:
$> make all
to statically check your files, compile and link them, generate docs and
 order from pizza hut all in one go.