[vtk-developers] Developer guidlines required

Sebastien BARRE seb-ml-a at barre.nom.fr
Wed Apr 11 08:48:06 EDT 2001


Hi

At 11/04/2001 13:36 +0530, Prabhu Ramachandran wrote:

>   (1) Not everyone reports what they do or what changes they make or
>   want to make.  So is this a good thing that I am doing or am I just
>   wasting everyone's bandwidth?

Same as David and Will, the mailing list should be more "verbose", we need 
more communication. So *yes*, as I told you privately, your comments are 
more than welcome. We read them (at least). But we don't answer to all of 
them publicly I guess.

>   I am aware of the Coding Standards
>   http://www.kitware.com/vtkhtml/vtkdata/CodeStyle.html and also the
>   copyright issues etc.  Are there others?  I did look around quite a
>   bit.

Respecting the style, etc.
I don't like some features of the VTK coding style (the brace position, 
which is not consistent with most scripting languages), but of course Emacs 
will do that for you with something like :

(defvar my-c-style
   '("my style"
     (c-backslash-column . 78)
     (c-basic-offset . 2)
     (c-comment-only-line-offset . (0 . 0))
     (c-offsets-alist . ((substatement-open    . +)
                         (statement-block-intro  . 0)
                         (case-label           . 0)))
     (c-tab-always-indent . t)
     )
   "My C Programming Style")

And you will likely be able to trigger that style only for filename 
belonging to VTK (something starting with vtk* for example), and keep your 
own style for the other files.

>   (3) How do developers actually maintain and run their code.  I mean
>   how exactly do you actually build the CVS tree?  Do you build it
>   right on the checked out CVS tree and use appropriate .cvisignore
>   files?  Or do you usually use a separate build dir?

I'm using the CVS, and like David I do not perform any raw "cvs commit", 
it's much too dangerous. I'm not using the .cvsignore either, you do not 
have to. I'm using a Windows GUI client, WinCVS, that is absolutely great. 
Committing is a matter of a couple of clicks. People rarely commit hundreds 
of files simultaneously, like you did last week :) I do not use the "local" 
directory either.

>   (4) How long(approximately) do the regression tests take to run on a
>   machine equivalent to a P III 450 with about 128MB RAM?

I'd say between 2 to 5 hours.

>   (5) Do you all run regression tests before you check in _anything_?
>   Or do you make the change and then track the nightly and continuous
>   build pages and then change things appropriately?

We had a long discussion about that privately, so you know my opinion. You 
will need to run all tests if you suspect that your changes have a big 
impact on the API. Otherwise, depending on your VTK knowledge, you will be 
able to run only a subset of the tests, and RTest.tcl will be of some help, 
for sure. As I told you, keeping an eye on both dashboards is the main 
point (no, in fact "fixing the dashboard" is the main point :). Committing 
Tcl tests or examples that stress/test your new class/feature is important 
too :)

>   (6) How do you handle multiple versions of VTK.  Right now I have
>   vtk-3.2 installed (system wide).  When you build the CVS tree and
>   run the tests etc., do you simply set LD_LIBRARY_PATH (or something
>   else under windows) and test?  What do you folks think is the best
>   way to all this.

I'm using Windows, but anyway changing the PATH is the only thing I have to 
do most of the time to switch from one version to the other. Sometimes 
changing PYTHONPATH, VTK_TCL is mandatory too.






More information about the vtk-developers mailing list