[CMake] Location of library to be linked changing over time

[Adolfo Rodríguez]

I understand perfectly what you say, but it doesn't look like it's the
currently implemented policy for retriggering find_library. Right now it
looks like it all depends on the value of the cached variable. I have a
somewhat similar use-case where I want to force find_package to look again
for a package, but my current solution has to be triggered by the user (but
we're OK with that).

Cheers

2009/4/30 Bill O'Hara <billtohara at gmail.com>

> Apologies - meant to hit reply all.
>
>
> ---------- Forwarded message ----------
> From: Bill O'Hara <billtohara at gmail.com>
> Date: 2009/4/30
> Subject: Re: [CMake] Location of library to be linked changing over time
> To: Adolfo Rodríguez <dofo79 at gmail.com>
>
>
> Hi Adolfo,
>
> Thanks for the suggestion. I understand that I can rerun cmake and have it
> find the new library version - perhaps even just a make rebuild_cache before
> each make test would work.
>
> However, what I really would like to do is not have to do that *manually*.
> Our users have libraries in one of two places, "a" and "b". If a library
> exists in "a" it should always be used even if we have previously linked
> against a version in "b". So I need to find some way to track dependencies
> between a user of a library and the library, and trigger a relink if a new
> version of a library has appeared in one of those locations with "a" always
> winning if a library is in both places.
>
> Let me rephrase the problem. I can add link_directories for "a" and "b" and
> have a build work by searching for libraries in those places at build time
> via -L flags to the compiler (not at cmake config time). But, that means
> cmake can't track dependencies because it doesn't know which file path we'll
> end up really linking with in the end.
>
> Does that make sense?
> Thanks
> b.
>
>
> 2009/4/30 Adolfo Rodríguez <dofo79 at gmail.com>
>
> Hi Bill,
>>
>> When you invoke find_library, FOO is created as a cache entry. As long as
>> FOO has a value (i.e., not FOO_NOTFOUND) find_library will not refresh its
>> contents on succesive runs of cmake. If you unset(FOO CACHE) and rerun
>> cmake, then the foo library will be searched for again.
>> Is this a good enough solution for your situation?
>>
>> Regards,
>>
>> Adolfo
>>
>> On Thu, Apr 30, 2009 at 9:55 PM, Bill O'Hara <billtohara at gmail.com>wrote:
>>
>>> Lets say I have a CMakeLists.txt that looks like this
>>>
>>> find_library(FOO foo /tmp/a /tmp/b)
>>> add_executable(bar bar.c)
>>> target_link_libraries(bar ${FOO})
>>> add_test(test_bar bar)
>>>
>>> then I run cmake, FOO is filled in with the located library from /tmp/b,
>>> and I run make all;make test. All is good. If I change /tmp/b/libfoo.a then
>>> when I run make test the executable is relinked before I execute it. All is
>>> good again.
>>>
>>> Now lets say a newer copy of the library appears in /tmp/a.
>>>
>>> When I run make test, what I'd like to happen is that we notice it has
>>> appeared, and relink against it because we prefer to use /tmp/a/libfoo.a if
>>> it exists (hence the order in the find_library).
>>>
>>> Is there a way to make that happen? I think if I wrote a raw makefile I
>>> could do this with vpaths or somesuch and still get the dependency checking
>>> ok. Is there a way with cmake?
>>>
>>> Thanks
>>> b.
>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.cmake.org/mailman/listinfo/cmake
>>>
>>
>>
>>
>> --
>> Adolfo Rodríguez Tsouroukdissian
>>
>> Robotics engineer
>> PAL ROBOTICS S.L
>> http://www.pal-robotics.com
>> Tel. +34.93.414.53.47
>> Fax.+34.93.209.11.09
>>
>
>
>


-- 
Adolfo Rodríguez Tsouroukdissian

Robotics engineer
PAL ROBOTICS S.L
http://www.pal-robotics.com
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090430/aed6cfa0/attachment.htm>