[vtk-developers] vtkMy build example

[Sebastien BARRE]

Hi Michael

I've redirected your email to vtkusers, if you do not mind.

At 1/17/2002 02:17 PM, Michael Halle wrote:

>I have just spent some time playing with the vtkMy build example in
>the 4.0 release.  Here are some observations that I've made.
>First, thanks for the example.  It's pretty clear to me that very few
>people who are not intimately familiar with the build process could
>have done it.  It's a great service to us module writers.

Thanks.

>Second, my general sense is that there's still too much to the process
>for simple modules.  There's a lot of logic left in the various cmake
>files.

Basically what I tried to do is put everything related to your project in 
the CMakeList.txt, and everything else (i.e. the wrapping mechanism) in the 
top vtkMy.cmake file, which you probably do not need to edit (did you ?).

>  To create a new module with a single class in it, I spent at
>least half an hour changing the module name from vtkMy in all the
>different files (and missing some at least three times).

I address this issue at the end of the README, but I acknowledge it might 
be prone to errors. So we could come up with a Perl script doing that.

>Third, what are the chances that later VTK or cmake builds will change
>the cmake logic contained in the vtkMy example files?  If there's a
>significant chance that the module cmake files will break in later
>releases, then I think that's an argument for factoring some of the
>logic out and putting it in a non-module-specific, central location.

Good point.
What we are going to do is make vtkMy part of the test process. Either as a 
dashboard, but most probably just as another test in the whole test 
process. Thus it will be built and tested on all our platforms and more.

>Is the need for so many VTKMY_ like cmake variables/parameters due to
>a scoping limitation in cmake?  I know very little about cmake, but it
>seems like some sort of local scoping would keep you from having to
>prefix every variable in every module.

Maybe I miss your point, but here are the only VTKMY_ vars I found:

VTKMY_CAN_BUILD
VTKMY_WRAP_TCL
VTKMY_WRAP_PYTHON
VTKMY_WRAP_JAVA

The first one is really useful. It assumes everything is set up correctly 
for build. If some requirements are not met, it is set to 0. In that case, 
the build won't be done. Usual trick.

The 3 others are just boolean that basically specify if you want to wrap 
your classes. I could have used VTK_WRAP_TCL, VTK_WRAP_PYTHON, 
VTK_WRAP_JAVA, but it has several drawback as they are inherited from the 
VTK cache file (either if you build it or you installed it from a binary 
release). This means that if you installed a binary a release, then the 
build would always wrap your classes automatically. This is not what 
everyone would do. So this layer on top of these 3 VTK_ vars just adds a 
bit more flexibility regardless of which wrapping feature has been 
activated in VTK.

As for:
VTKMY_BINARY_DIR
VTKMY_SOURCE_DIR
these are created automatically by CMake, using the project name VTKMY.

>I'd certainly offer to help out in implementing a solution, but
>(coming full circle) the build process is sufficiently complex that
>it's quite hard for an outsider to figure out the important details
>without intensive study.

What I think would be could is that Perl script (see above). This could be 
used to start a fresh project with your own prefix.

Thanks for your feedback

--
Sebastien Barre