From: Brad K. <bra...@ki...> - 2003-10-08 13:53:49
|
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 |
From: Ian S. <ian...@st...> - 2003-10-08 14:30:36
|
Peter, Would it be possible to shift the existing configure scripts into your makefile branch, so that the makefile buildsystem continued to work? Given how little the configure scripts have changed over the last few years, I can't imagine that it would be much effort to keep the configure scripts in sync with the try-compile tests. Ian. > -----Original Message----- > From: Brad King [mailto:bra...@ki...] > Sent: Wednesday, October 08, 2003 2:53 PM > To: Fred Wheeler > Cc: VXL Maintainers; Bill Hoffman > Subject: [Vxl-maintainers] 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 > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Peter V. <Pet...@es...> - 2003-10-08 14:43:29
|
> Would it be possible to shift the existing configure scripts into your > makefile branch, so that the makefile buildsystem continued to work? All right, done. -- Peter. |
From: Ian S. <ian...@st...> - 2003-10-08 14:45:43
|
Oops, I meant "in theory", not "now". I don't believe that Brad has done the work to allow CMake to use the new system yet. Care to move them back? Ian. > -----Original Message----- > From: Peter Vanroose [mailto:Pet...@es...] > Sent: Wednesday, October 08, 2003 3:43 PM > To: Ian Scott > Cc: 'Brad King'; Vxl-maintainers (E-mail) > Subject: RE: [Vxl-maintainers] VXL and ITK > > > > Would it be possible to shift the existing configure > scripts into your > > makefile branch, so that the makefile buildsystem continued to work? > > All right, done. > > > -- Peter. > |
From: Peter V. <Pet...@es...> - 2003-10-08 15:11:53
|
> I don't believe that Brad has done the work > to allow CMake to use the new system yet. > > Care to move them back? Done. I didn't know CMake was using these files. -- Peter. |
From: Ian S. <ian...@st...> - 2003-10-09 14:30:32
|
> -----Original Message----- > From: Brad King [mailto:bra...@ki...] > > 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. This is an obvious improvement that has been waiting for someone to have enough interest in. One question though. Would it be really necessary for the legacy autoconf code to use the separate .cxx files? Given how rarely the configure file has changed over the past few years, I would have though that we could leave the legacy code, and only modify it to use the separate .cxx files if we need to make a major *functional change to the configuration system. Or do you plan to make major *functional changes? * by functional change I mean a change that would produce a different vcl, as distinct from an implementation change to the way the configure system works. > compilers. Then new compilers will be supported automatically. That would be very nice. Ian. |
From: William A. H. <bil...@ny...> - 2003-10-09 18:21:41
|
At 10:31 AM 10/9/2003, Ian Scott wrote: >> -----Original Message----- >> From: Brad King [mailto:bra...@ki...] >> >> 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. > >This is an obvious improvement that has been waiting for someone to have >enough interest in. > >One question though. Would it be really necessary for the legacy autoconf >code to use the separate .cxx files? Given how rarely the configure file has >changed over the past few years, I would have though that we could leave the >legacy code, and only modify it to use the separate .cxx files if we need to >make a major *functional change to the configuration system. Or do you plan >to make major *functional changes? No major change is planned. It was just thought that to avoid code duplication, it would be best to share if possible. However, that is up to you folks. We actually have started on this. We have modified the configure.in a bit so that it generates the cmake code for us. So, it generates a test.cxx file with all the tests in it, but they are separated with ifdef's. Something like: #ifdef VCL_TEST_BOOL .... #endif #ifdef VCL_... ... #endif Then to try the test, you compile with -DVCL_TEST_BOOL and you get just that test,but the code is all in one .cxx file for easy maintenance. To test it, we use cmake and configure to generate the same .h files using the same .h.in files and make sure we are getting the same answers. So, it is up to you if you want to back fit the autoconf script. >* by functional change I mean a change that would produce a different vcl, >as distinct from an implementation change to the way the configure system >works. No change. >> compilers. Then new compilers will be supported automatically. > >That would be very nice. As a phase two of this process, it might be nice to add more try compile tests, and remove more of the ifdef thisCOMPILER stuff that is still in vcl. -Bill |