[CMake] Plural includes, pre-2.6.1 alternative to HINTS, persistence, C99

Alexander Neundorf a.neundorf-work at gmx.net
Tue Nov 4 15:58:59 EST 2008


On Tuesday 04 November 2008, Jed Brown wrote:
> 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.

I haven't seen XXX_INCLUDE_PATH in use.

XXX_INCLUDE_DIR is usually one directory, searched using FIND_PATH, and so 
usually ends up in the cache. 
Then one project can need multiple include dirs, so these 
XXXcomponent1_INCLUDE_DIR and XXXcomponent2_INCLUDE_DIR are then usually 
merged into a XXX_INCLUDE_DIRS variable:
set(XXX_INCLUDE_DIRS ${XXXcomponent1_INCLUDE_DIR}
                     ${XXXcomponent2_INCLUDE_DIR} )

Instead of XXX_INCLUDE_DIRS sometimes also XXX_INCLUDES is used. I wouldreco
>
>
> 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.  

Where do you see the problem ?

> 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.  

Yes, I think so.

> Now
> find_package_handle_standard_args() will make FOO_LIBRARIES an advanced
> cache entry 

No, find_package_handle_standard_args() doesn't mark anything as advanced. 
Where did you see this ?

> and if the user edits this, it shouldn't get blasted by
> reconfigure *unless* they change FOO_DIR.

Values in the cache are only overwritten if the FORCE option is used for 
SET().

> It seems like a fair number of modules use the environment variable
> FOO_DIR as a hint to find_library(), etc.  

I wouldn't recommend this.
With cmake 2.6 you can set the CMAKE_PREFIX_PATH environment variable to point 
to your custom install locations.

Alex

P.S. can you split your initial mail into multiple small ones, one for each 
topic ? Makes handling it a bit easier.


More information about the CMake mailing list