[cmake-developers] [CMake] Debugging find_package() search behavior?

Robert Dailey rcdailey.lists at gmail.com
Tue Aug 29 17:28:09 EDT 2017


One other thing: Is there a way to make find_package() default to
CONFIG mode? Right now it seems to search MODULE first, then CONFIG.
But right now the only way to enable config is to explicitly use the
CONFIG option or make sure CMake can't find a find module by
manipulating CMAKE_MODULE_PATH.

On Tue, Aug 29, 2017 at 12:51 PM, Robert Dailey
<rcdailey.lists at gmail.com> wrote:
> On Tue, Aug 29, 2017 at 12:12 PM, Rolf Eike Beer <eike at sf-mail.de> wrote:
>> Am Dienstag, 29. August 2017, 11:21:42 schrieb Robert Dailey:
>>> Ok I debugged find_path() code in CMake and I determined the problem.
>>> First, let me explain what I'm doing a little more...
>>>
>>> I build third party libraries on demand during configure step in
>>> CMake. I do so via execute_process() to invoke another CMake instance,
>>> that builds and installs a library. This is similar to how
>>> ExternalProject_Add() works, but forces it to happen at configure time
>>> so I can use find_package() afterwards to find the library I just
>>> built.
>>
>> The trick with ExternalProject_Add is to also build your project with it, and
>> not with add_subdirectory, i.e. the CMakeLists.txt that drives the build needs
>> to be one level above your actual project. This way all things are done in
>> order, so the dependencies are build before your main project.
>
> That's not going to work since for multi-configuration generators you
> want to be able to edit and build your code through the IDE, not via
> command line.
>
> Regarding find modules: it seems simpler at this point to just redo
> the install logic of upstream libraries using configuration packages
> instead, that way I can have finer control over how packages are
> found. Plus it's good for upstream repositories to be able to
> contribute this back.
>
> Thanks to everyone for their feedback. I have a much better
> understanding of this now, although I still strongly feel this is
> crazy complex. But nothing we can do about that I guess... it's just
> the nature of things.


More information about the cmake-developers mailing list