I would be definitely interested in FindACE and FindTAO scripts, and although I currently don&#39;t have much spare time, I&#39;d be happy to contribute with whatever I can to the writing of such scripts. I currently use the LibFindMacros.cmake script posted here [1], but I&#39;m considering moving to the FIND_PACKAGE_HANDLE_STANDARD_ARGS script [2]. You might also find this link useful [3].<br>
<br>Cheers<br><br>[1] <a href="http://cmake.org/Wiki/CMake:How_To_Find_Libraries" target="_blank">http://cmake.org/Wiki/CMake:How_To_Find_Libraries</a><br>[2] <a href="http://www.cmake.org/cmake/help/cmake2.6docs.html#module:FindPackageHandleStandardArgs">http://www.cmake.org/cmake/help/cmake2.6docs.html#module:FindPackageHandleStandardArgs</a><br>
[3] <a href="http://www.cmake.org/Wiki/CMake:Improving_Find*_Modules" target="_blank">http://www.cmake.org/Wiki/CMake:Improving_Find*_Modules</a><br><br><div class="gmail_quote">On Tue, Apr 21, 2009 at 2:55 PM, Gregory Peele ARA/CFD <span dir="ltr">&lt;<a href="mailto:gpeele@ara.com">gpeele@ara.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I have a question about the expected behavior of Find scripts when a found library or program has transitive linking dependencies on other shared libraries that are not available on the system library path, but visible to Find scripts because of the CMake search paths.  I&#39;m using GCC 4.2 on Linux-i686 and Linux-x86_64, not sure which other systems have similar linking behavior.<br>

<br>
For example, if I call FIND_PACKAGE (&quot;DevIL&quot;), it will pick up my custom IL, ILU, and ILUT libraries, but when my software tries to link against it, GCC bombs out because it can&#39;t find IL link dependencies such as lcms or mng that are not installed on my system but are provided by my project, and it will use the system libpng / libz rather than my custom ones (not really a problem, but not expected either.)  Looking at FindDevIL.cmake, it does not attempt to search for these dependencies.  On the other hand, if I call FIND_PACKAGE (&quot;PNG&quot;) it will correctly pick up my custom libz as a dependency and include it in PNG_LIBRARIES.<br>

<br>
Which of these two behaviors should be the &quot;expected&quot; one?  I&#39;m in the process of writing a fair number of Find scripts so I want to do it the &quot;right&quot; way (and be able to build my project of course.)<br>

<br>
Incidentally, I&#39;m writing Find scripts for the following libraries: CppUnit, LCMS, OGDI (an optional GDAL dependency with support for oddball military formats), ACE, TAO, MNG, PROJ4, Presagis OpenFlight, and a FindUUID script which attempts to determine the &quot;native&quot; support for UUID manipulation (e.g. Rpcrt4.lib on Windows, e2fslibs libuuid on Linux) and reports which style of UUIDs it found as well as necessary link and include options.  I would be happy to submit any of them if there&#39;s interest, but they&#39;re only really tested for my particular project on Linux and Windows.<br>

<br>
Thanks,<br>
Gregory Peele, Jr.<br>
Applied Research Associates, Inc.<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Adolfo Rodríguez Tsouroukdissian<br><br>Robotics engineer<br>PAL ROBOTICS S.L<br><a href="http://www.pal-robotics.com">http://www.pal-robotics.com</a><br>Tel. +34.93.414.53.47<br>
Fax.+34.93.209.11.09<br>