[CMake] Volunteering to maintain two new Find Modules

Philip Lowman philip at yhbt.com
Fri Jan 9 07:32:52 EST 2009


On Thu, Jan 8, 2009 at 5:22 PM, Albert Astals Cid <aacid at kde.org> wrote:

Ok, so at the end it is
>
> find_path(LibOpenJPEG_INCLUDE_DIR openjpeg.h
>          PATH_SUFFIXES openjpeg openjpeg-1.0)
>
> find_library(LibOpenJPEG_OPENJPEG_LIBRARY openjpeg)
>
> if (LibOpenJPEG_OPENJPEG_LIBRARY)
>  set (LibOpenJPEG_LIBRARIES ${openjpeg_LIBRARY})
> endif (LibOpenJPEG_OPENJPEG_LIBRARY)


If you spot any find modules with this syntax this is wrong. The reason why
is if LibOpenJPEG_OPENJPEG_LIBRARY is NOTFOUND then LibOpenJPEG_LIBRARIES
will not be set to NOTFOUND and if the user is linking a target against the
LIBRARIES variable they will get no error because the variable will expand
to nothing.

Please fix this in your new modules and if you see it anywhere report it as
a bug.


> But this noise in the list isn't worth if we don't get a proper ok/ko from
> the
> package maintainers regarding the fact of having this kind of FindFoo files
> in cmake upstream or not.


I will happily check in FindOpenJPEG for you once it's cleaned up should you
decide not to want to get CVS access and maintain it yourself.  It's
packaged in Debian which definitely qualifies it as used enough to check in.

As others have commented, please drop the "Lib" prefix unless the library is
universally referred to as "libopenjpeg" in normal speech or if shortening
it to just "openjpeg" would cause confusion.  An example of a module that
probably should keep the "lib" prefix currently in CVS would be
FindLibXml2.  Calling it FindXml or FindXml2 would just cause confusion.
Unless this is the case with your module dropping the "lib" would be
adviseable.

-- 
Philip Lowman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090109/f1fd4126/attachment.htm>


More information about the CMake mailing list