On Thu, Jan 8, 2009 at 1:59 AM, Hendrik Sattler <span dir="ltr"><<a href="mailto:post@hendrik-sattler.de">post@hendrik-sattler.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Am Wednesday 07 January 2009 23:54:05 schrieb Albert Astals Cid:<br>
<div><div></div><div class="Wj3C7c">> Hi, i'm new to the list, so i'm not sure if this is the correct procedure,<br>
> i read a bit in the wiki and it seems it is, so here i am.<br>
><br>
> I want to add upstream the two attached modules so we don't have to<br>
> maintain them in poppler. I'll have to maintain them upstream but maybe<br>
> more people will use them and find bugs/improve.<br>
><br>
> They are pretty simple and work for us in poppler.<br>
<br>
</div></div>Please don't do:<br>
find_library(LIBOPENJPEG_LIBRARIES openjpeg)<br>
<br>
as it makes it hard to use LIBOPENJPEG_LIBRARIES directly in<br>
target_link_libraries().<br>
Instead, use a variable for the cache, say 'openjpeg_LIBRARY' and do<br>
find_library(openjpeg_LIBRARY openjpeg)<br>
if (openjpeg_LIBRARY)<br>
set (LIBOPENJPEG_LIBRARIES $(openjpeg_LIBRARY))<br>
endif (openjpeg_LIBRARY)<br>
<br>
You also don't need the first-level if-else-endif as find_path and<br>
find_library will do nothing if the variable is already defined, just don't<br>
reset the variables.<br>
<br>
This makes the modules lik 5 lines which may as well be included directly in a<br>
project. There is nothing complicated to do. It would be a nightmare to have<br>
an official module for every library out there.</blockquote><div><br>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.<br>
<br>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.<br>
<br>Thoughts?<br><br>Toplevel CMakeLists.txt:<br>==============<br>FIND_PROJECT(FOO)<br><br>FindFOO.cmake:<br>=============<br>INCLUDE(SimplePackageFind)<br>SimplePackageFind(FOO foo.h foo)<br><br>SimplePackageFind.cmake:<br>
=============<br>MACRO(SimplePackageFind _package _header _library)<br>
<br> find_path(${_package}_INCLUDE_DIR NAMES ${_header})<br>
find_library(${_package}_LIBRARY NAMES ${_library})<br>
<br>
include(FindPackageHandleStandardArgs)<br>
find_package_handle_standard_args(${_package} DEFAULT_MSG ${${_package}_LIBRARY} ${${_package}_header} )<br>
<br>
set(${_package}_LIBRARIES ${${_package}_LIBRARY} )<br>
set(${_package}_INCLUDE_DIRS ${${_package}_INCLUDE_DIR})<br>
<br>
ENDMACRO()<br><br></div></div><br>-- <br>Philip Lowman<br>