[CMake] Volunteering to maintain two new Find Modules

[Philip Lowman]

On Thu, Jan 8, 2009 at 1:59 AM, Hendrik Sattler <post at hendrik-sattler.de>wrote:

> Am Wednesday 07 January 2009 23:54:05 schrieb Albert Astals Cid:
> > Hi, i'm new to the list, so i'm not sure if this is the correct
> procedure,
> > i read a bit in the wiki and it seems it is, so here i am.
> >
> > I want to add upstream the two attached modules so we don't have to
> > maintain them in poppler. I'll have to maintain them upstream but maybe
> > more people will use them and find bugs/improve.
> >
> > They are pretty simple and work for us in poppler.
>
> Please don't do:
>  find_library(LIBOPENJPEG_LIBRARIES openjpeg)
>
> as it makes it hard to use LIBOPENJPEG_LIBRARIES directly in
> target_link_libraries().
> Instead, use a variable for the cache, say 'openjpeg_LIBRARY' and do
>  find_library(openjpeg_LIBRARY openjpeg)
>  if (openjpeg_LIBRARY)
>    set (LIBOPENJPEG_LIBRARIES $(openjpeg_LIBRARY))
>  endif (openjpeg_LIBRARY)
>
> You also don't need the first-level if-else-endif as find_path and
> find_library will do nothing if the variable is already defined, just don't
> reset the variables.
>
> This makes the modules lik 5 lines which may as well be included directly
> in a
> project. There is nothing complicated to do. It would be a nightmare to
> have
> an official module for every library out there.


I thought the same initially before reading this.  Then I realized that
having a CMake Find module there really isn't a big deal.  I mean, who cares
if there are a couple of hundred files in share/cmake-2.x/modules?  That
just means that there are a couple of hundred libraries that CMake comes
configured out of the box ready to use.  That's a good thing (provided these
libraries are at least used to a certain extent).  It doesn't matter how
many are in the folder since usually you're searching for a particular one
and not reading through every single file there. People worry a lot about
maintenance, but honestly, how many open-source C/C++ libraries out there
regularly change their core include filename and/or library name.  The
answer is not many.

I guess what I'm proposing is something similar to the following for
"trivial" modules.  These modules could also be modified to not call the
helper macro as needed while maintaining backwards compatibility.  Also
people could simply include the macro and call it directly without making a
module if they wanted.  The goal would be to have something that would work
for most simple C/C++ libraries that have only one include path and one
library.

Thoughts?

Toplevel CMakeLists.txt:
==============
FIND_PROJECT(FOO)

FindFOO.cmake:
=============
INCLUDE(SimplePackageFind)
SimplePackageFind(FOO foo.h foo)

SimplePackageFind.cmake:
=============
MACRO(SimplePackageFind _package _header _library)

   find_path(${_package}_INCLUDE_DIR NAMES ${_header})
   find_library(${_package}_LIBRARY NAMES ${_library})

   include(FindPackageHandleStandardArgs)
   find_package_handle_standard_args(${_package} DEFAULT_MSG
${${_package}_LIBRARY} ${${_package}_header} )

   set(${_package}_LIBRARIES        ${${_package}_LIBRARY} )
   set(${_package}_INCLUDE_DIRS  ${${_package}_INCLUDE_DIR})

ENDMACRO()


-- 
Philip Lowman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090108/5fbd44be/attachment-0001.htm>