[CMake] Canonical use of FindPackageHandleStandardArgs
Mateusz Loskot
mateusz at loskot.net
Sat Mar 6 13:22:56 EST 2010
Ryan Pavlik wrote:
> I took a quick look at your MySQL script and can offer these
> suggestions:
Ryan,
Thank you very much for your valuable comments
and I'm going to improve my scripts according them.
> - Be sure to set the plural versions of the variables (INCLUDE_DIRS,
> LIBRARIES) to include the dependencies (these should not be cached),
> and leave the singular version for just a single path/file (these
> should be cached, as by default
Good point. I'll have to re-read the Modules/readme.txt guidelines
> In your emailed example: I presume the mylib in step 2 is different
> than the mylib in step 1 and 3/4, because otherwise you have an
> infinitely-recursive find script. Please clarify, preferably with an
> actual example.
It's an interesting observation. I'm not
> If the lib in step 2 is a dependency, convention varies, but it seems
> prudent to me to always find dependencies quietly: this prevents
> them from showing up in lists from FeatureSummary, etc. Anything you
> require in that dependency package should be passed to your
> find_package_handle_standard_args call which will make the
> appropriate noises if it shouldn't be quiet and it can't be found.
OK, I think I got the point.
> If you're not doing find scripts that depend on other find scripts,
All the scripts I've written so far are standalone scripts.
> then look in the archives from a month or so ago: I posted some
> "sample" find scripts that are modern and clean in style.
You mean the mailing list archives or a repository?
> You can also take a peek at everything except FindDirectShow.cmake (I
> didn't write that one or rewrite it beyond running my cleanup app on
> it, and it's sorely in need of work) here:
> http://github.com/rpavlik/vrpn/tree/master/vrpn/cmake/
Great, I'll check it.
> Hope this helps!
Absolutely, it helps! I'm glad getting my scripts reviewed.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
More information about the CMake
mailing list