[Vxl-maintainers] RE: VXL and ITK

[Wheeler, F. W (Research) <wh...@cr...>]

Brad,

Sorry for the delay.  I've been away the past few days.

This all sounds great to me, and I have not seen any objections from the
list - which is what really matters.  I think everyone will benefit if we do
a better job at sharing vnl.  It is fine with me to move to CMake for
try-compile stuff.  

I will work on getting a bcc dashboard build going for VXL.  Must bcc be run
in Windows or is it available on other platforms?

Fred


> -----Original Message-----
> From: Brad King
> Sent: Wednesday, October 08, 2003 9:53 AM
> To: Fred Wheeler
> Cc: VXL Maintainers; Bill Hoffman
> Subject: VXL and ITK
> 
> 
> Fred,
> 
> I just read through your updated implementation of 
> VXLConfig.cmake.  Very
> nice!  Thanks for your help with that.
> 
> I've been looking at upgrading ITK's copy of vnl and adding 
> support for
> using an external VXL to build ITK.  Once it's working we'll 
> run an ITK
> dashboard that uses a nightly VXL to keep it working.  However, ITK
> supports the Borland 5.5 compiler for windows (free 
> command-line tools).
> 
> Kitware would like to contribute support for this compiler back to VXL
> proper so that we don't have to port vnl every time we upgrade ITK's
> version.  We can do the initial port for most of VXL's tree, 
> but it will
> have to be supported by the VXL community after that.  Also, 
> I don't think
> there is a machine here with enough time in the night to run VXL's
> dashboard for borland in addition to the dashboards it's 
> already running.
> 
> The approach we plan to take is to convert the autoconf 
> try-compile tests
> over to individual .cxx files.  Then they can be shared between the
> configure script and the CMake build process.  We can do the 
> separation
> and the CMake test implementation, but someone else will have 
> to modify
> the autoconf code to use the separate .cxx files.  Once CMake 
> is used to
> drive the vcl configuration process, it will be usable for Windows
> compilers automatically.
> 
> CMake also keeps the try-compile results in the cache, so 
> re-configuring a
> build tree on UNIX after the first run will be much faster than it is
> currently when the configure script re-runs.  We can also speed-up the
> initial configuration process on Windows by having CMake load 
> pre-computed
> test result files that stop the tests from running at all on known
> compilers.  Then new compilers will be supported automatically.
> 
> Thoughts?
> -Brad
>