Tools and ways for our development

[Matthias Kupfer]

Hi,

at present I work for mid-sized company for ticketing, parking and mobile 
solutions in Germany (and Great Britain). I personally work in a project for 
railway services (using gsm-r network). To understand the tools given below I 
want to figure out our target and environment in short. We develop for 
embedded Linux systems with ARM-CPU and Qt-Framework. Therefore C++ was and 
is used as programming language.

Apart from he usual tools like
- make-alike build tools (written in perl - a project specific one)
- regular make files for some special targets
- SVN for source code management
we use some interesting tools to keep the source readable and to preserve a 
minimum of source quality automatically (bear in mind we use C++ instead of 
C, for our purpose we need to alter some tools for our needs):

- Hudson for automatic build and checking the source (see below)
- cpplint.py (by Google) for some checking the source
- cppcheck for another check of the source
- doxygen for checking the missing documentation (in that special case check 
only by tricky configuration instead of costly generating all documentation 
files)
- format the source code (after agreement of all devs) in a uniform style with 
astyle before commit (for ReactOS better as commit hook)
- finally we gather all check results in one table and mark the results for 
hudson as stable (if no errors), failed (in case of any errors), unstable (in 
case of some low-prio warnings)

Maybe we can think about some of them, because even if some problems of 
development remains, it might give us some edge and may also attract some 
devs. I don't make any suggestions, but I want to tell you how others work.

Matthias

PS: We are the first project in the company going that way and other project 
groups would like to adapt the way, because they see the benefit for 
their/other/future projects.
-- 
Matthias Kupfer          phone [phone]
Wilhelm-Firl-Straße 21   mobile [phone]
09122 Chemnitz, Germany

[Pierre Schweitzer]

Hi,

answering inlined.

Le jeudi 29 septembre 2011 à 23:06 +0200, Matthias Kupfer a écrit :
> Hudson for automatic build and checking the source (see below)

Instead of using hudson, we're using buildbot here.
> cpplint.py (by Google) for some checking the source

I didn't know that tool, I will look at it.
> cppcheck for another check of the source

You can find daily cppcheck runs at:
http://fezile.reactos.org/cppcheck/. I'm currently working on
configuration to get runs more and more accurate.
> doxygen for checking the missing documentation (in that special case check
>
> only by tricky configuration instead of costly generating all documentation 
> files)

Since most of the ReactOS is not documented, or not documented in a
doxygen way, this would require high amount of time. Especially since
running doxygen takes times on ReactOS.
But at least, this sentence raises a good ReactOS problem:
documentation. A real effort should be done on that point.

As a reminder, you can find daily doxygen output at:
http://doxygen.reactos.org/
> format the source code (after agreement of all devs) in a uniform style with
>
> astyle before commit (for ReactOS better as commit hook)

This could be indeed a good idea... Problem is old code in quite bad
shape.

As a reminder, we also have a coding style guide available here:
http://www.reactos.org/wiki/Coding_Style
> finally we gather all check results in one table and mark the results for
>
> hudson as stable (if no errors), failed (in case of any errors), unstable (in 
> case of some low-prio warnings)

This is somehow what we have with testman, even if it should probably be
improved to get more results.

As a reminder, you can find testman at: http://www.reactos.org/testman

Regards,
Pierre