From: Brad K. <bra...@ki...> - 2003-09-10 20:14:34
|
Hello vxl-maintainers, After some preliminary discussion with Ian Scott and Amitha Perera, I have the following proposal for changing the way VXL is packaged and used by outside projects. Currently an external project finds and uses VXL like this: # User sets "VXL_BINARY_PATH" to point at a VXL build tree. SET(VXL_BINARY_PATH "" CACHE PATH "VXL binary path") IF(VXL_BINARY_PATH) INCLUDE(${VXL_BINARY_PATH}/UseVXL.cmake) # Use VXL... ENDIF(VXL_BINARY_PATH) This seems pretty clean, but it has several drawbacks: 1.) UseVXL imports a bunch of CMakeCache.txt entries from VXL into the user project. Not all may be desirable. Also, this approach does not work well when the user project uses more than one CMake-built library. Loading entries from both cache files will invisibly switch cache values back and forth between the values from the two libraries. 2.) There is no clear separation between finding VXL and using it. There is no way to get VXL's include directories, library directories, or build configuration options without importing everything. 3.) If the external project is another library that itself exports settings to other projects, it is difficult to forward the VXL include/library paths properly. This is important when the external project has header files that include VXL headers but does not expect its users to include VXL headers directly. I went through these headaches with VTK and ITK over the past few years. The LOAD_CACHE approach to UseFOO.cmake files is undesireable. As a solution for VTK and ITK, I devised a newer scheme based on a VTKConfig.cmake file created by the build process. This approach is described in the CMake book in section 6.7. I propose to implement a VXLConfig.cmake based approach to packaging VXL for use by outside projects. With the proposed change, the above VXL_BINARY_PATH/UseVXL.cmake approach will still work unchanged (although it will be implemented differently), but the following will be possible and preferred: # User sets "VXL_DIR" to point at a VXL build tree or possibly in the # future to an installed tree. FIND_PACKAGE(VXL) IF(VXL_FOUND) INCLUDE(${VXL_USE_FILE}) # Use VXL... ENDIF(VXL_FOUND) With this approach, the only CMake cache entry that is introduced into the user's project is VXL_DIR. It points to the directory containing a VXLConfig.cmake file that FIND_PACKAGE loads. That file contains a bunch of SET(VXL...) commands to describe VXL's settings. Selecting a different VXL build tree involves setting VXL_DIR in the cache, and all other settings change to those imported from the new location automatically. This approach solves the issues mentioned above as follows: 1.) Only VXL_DIR is set in the cache. No LOAD_CACHE is used. 2.) After VXL_DIR is set, FIND_PACKAGE imports project settings but does not actually invoke any INCLUDE_DIRECTORIES, LINK_DIRECTORIES, or similar commands. It only sets variables like VXL_INCLUDE_DIRS. 3.) Settings can be exported to another project by exporting the value of VXL_DIR and other values important to the project. The VXL include directories used by the project can be appended to its list and exported as something like FOO_INCLUDE_DIRS. Comments? -Brad |
From: Ian S. <ian...@st...> - 2003-09-11 14:22:19
|
I vote for the proposal. Having spent some considerable time writing Manchester's internal dashboard system with continuous builds I can attest to the unpleasantness of the current LOAD_CACHE method - although I was eventually able to get it to work. Project A loads VXL's cache, Project B loads A's and VXL's cache. Project C loads A's, B's and VXL's cache, etc. I suspect that Brad's proposal will make such multi-project interdepencies easier to deal with. Although we may be forced to rewrite our existing system. This modification to VXL's CMake configuration will not affect VXL itself, since VXL is of course build-system agnostic. A further bit of background. I know that Chuck Stewart has been trying to write code using ITK and VXL, and found it difficult due to the problems Brad describes. Since they both use CMake, it would be useful if they both used it in a compatible way. Ian. > -----Original Message----- > From: Brad King [mailto:bra...@ki...] > Sent: Wednesday, September 10, 2003 9:14 PM > To: VXL Maintainers > Cc: Ian Scott; Amitha Perera; Chuck Stewart > Subject: Support for FIND_PACKAGE(VXL) > > > Hello vxl-maintainers, > > After some preliminary discussion with Ian Scott and Amitha > Perera, I have > the following proposal for changing the way VXL is packaged > and used by > outside projects. > > Currently an external project finds and uses VXL like this: > > # User sets "VXL_BINARY_PATH" to point at a VXL build tree. > SET(VXL_BINARY_PATH "" CACHE PATH "VXL binary path") > IF(VXL_BINARY_PATH) > INCLUDE(${VXL_BINARY_PATH}/UseVXL.cmake) > > # Use VXL... > > ENDIF(VXL_BINARY_PATH) > > This seems pretty clean, but it has several drawbacks: > > 1.) UseVXL imports a bunch of CMakeCache.txt entries from VXL into > the user project. Not all may be desirable. Also, this approach > does not work well when the user project uses more than one > CMake-built library. Loading entries from both cache files > will invisibly switch cache values back and forth between the > values from the two libraries. > > 2.) There is no clear separation between finding VXL and using it. > There is no way to get VXL's include directories, library > directories, or build configuration options without importing > everything. > > 3.) If the external project is another library that itself exports > settings to other projects, it is difficult to forward the > VXL include/library paths properly. This is important when > the external project has header files that include VXL headers > but does not expect its users to include VXL headers directly. > > I went through these headaches with VTK and ITK over the past > few years. > The LOAD_CACHE approach to UseFOO.cmake files is undesireable. As a > solution for VTK and ITK, I devised a newer scheme based on a > VTKConfig.cmake file created by the build process. This approach is > described in the CMake book in section 6.7. > > I propose to implement a VXLConfig.cmake based approach to > packaging VXL > for use by outside projects. With the proposed change, the above > VXL_BINARY_PATH/UseVXL.cmake approach will still work > unchanged (although > it will be implemented differently), but the following will > be possible > and preferred: > > # User sets "VXL_DIR" to point at a VXL build tree or possibly in the > # future to an installed tree. > FIND_PACKAGE(VXL) > IF(VXL_FOUND) > INCLUDE(${VXL_USE_FILE}) > > # Use VXL... > > ENDIF(VXL_FOUND) > > With this approach, the only CMake cache entry that is > introduced into the > user's project is VXL_DIR. It points to the directory containing a > VXLConfig.cmake file that FIND_PACKAGE loads. That file > contains a bunch > of SET(VXL...) commands to describe VXL's settings. > Selecting a different > VXL build tree involves setting VXL_DIR in the cache, and all other > settings change to those imported from the new location automatically. > > This approach solves the issues mentioned above as follows: > > 1.) Only VXL_DIR is set in the cache. No LOAD_CACHE is used. > > 2.) After VXL_DIR is set, FIND_PACKAGE imports project settings > but does not actually invoke any INCLUDE_DIRECTORIES, > LINK_DIRECTORIES, > or similar commands. It only sets variables like > VXL_INCLUDE_DIRS. > > 3.) Settings can be exported to another project by exporting the > value of VXL_DIR and other values important to the project. > The VXL include directories used by the project can be appended > to its list and exported as something like FOO_INCLUDE_DIRS. > > Comments? > -Brad > |
From: Brad K. <bra...@ki...> - 2003-09-15 19:25:10
Attachments:
vxl_cmake_package.diff.gz
|
On Thu, 11 Sep 2003, Ian Scott wrote: > I vote for the proposal. > ... > A further bit of background. I know that Chuck Stewart has been trying > to write code using ITK and VXL, and found it difficult due to the > problems Brad describes. Since they both use CMake, it would be useful > if they both used it in a compatible way. Since there were no objections, I implemented the proposal in my working copy of VXL. It was actually easier than expected. Building a trivial outside project as well as RPI's Retina project worked the first try using the new implementation and both the old (include UseVXL directly) and new (use FIND_PACKAGE) ways of loading VXL from the external project. How should I proceed now? I see several options: 1.) Just check it in and then fix any problems ASAP. 2.) Check it in on a branch for some people to try. 3.) Post a patch for some people to try. I've attached a diff. cd vxl; zcat ~/vxl_cmake_package.diff.gz | patch -p0 To give you an idea of the scope of the changes, here is the output of "cvs -nq update": M CMakeLists.txt R UseVXL.cmake A config/cmake/UseVXL.cmake A config/cmake/VXLConfig.cmake.in A config/cmake/VXLStandardOptions.cmake M core/CMakeLists.txt M vcl/CMakeLists.txt -Brad |
From: Peter V. <Pet...@es...> - 2003-09-15 20:18:39
|
> 3.) Post a patch for some people to try. I would prefer this; otherwise, the CVS repository gets "polluted" with branches... -- Peter. |