A minor documentation nit: readme.txt says XXX_INCLUDE_PATH was considered bad because a path includes an actual filename
but variable type PATH = Directory chooser dialog while FILEPATH refers to a file. So this doesn't seem to be a valid argument against XXX_INCLUDE_PATH, but we should agree on *something* and all other forms should be clearly labeled as deprecated in the documentation. To clarify a question in my previous message, is there a recommended method for finding packages that contain multiple libraries? FindQt4, for instance, creates a huge list of cache entries for each individual library within the package. This doesn't seem like a good solution when the list of libraries is not known apriori or may change with a new release. Dumping all the entries in a single variable isn't okay either unless the module provides a way to (on reconfigure) change all the paths in that list. It seems like I always want a FOO_DIR cache entry to use as a hint to find FOO_LIBRARIES. Now find_package_handle_standard_args() will make FOO_LIBRARIES an advanced cache entry and if the user edits this, it shouldn't get blasted by reconfigure *unless* they change FOO_DIR. It seems like a fair number of modules use the environment variable FOO_DIR as a hint to find_library(), etc. This is fine if the user knows in advance that the library won't be found by default, so they need to set the environment variable. However, if the user doesn't set these before running cmake, they don't have an intuitive way to trigger a reconfigure. The most reliable way I've found is to start over from scratch with the environment variable set (i.e. rm -r * in the build directory). This is ugly and motivation for the cache entry FOO_DIR mentioned above (which mirrors the environment variable, if set, on the first pass). The problem is that there is a bit of boilerplate to make this work, hence maintenance of many modules is a pain. Jed
pgpnNL68UD1tc.pgp
Description: PGP signature
_______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
