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.
> -----Original Message-----
> From: Brad King [mailto:brad.king@...]
> 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")
> # Use VXL...
> 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
> 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.
> # Use VXL...
> 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,
> or similar commands. It only sets variables like
> 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.