Hi
In regard to your issue with copying the library to the executable
directory, I wrote a little script for my software which ensures, that
a library is existent at the same path then the application. I
attached the script and the called runner.
You call it with:
IF ( ( WIN32 OR CYGWIN ) AND ( ${LIB_TYPE} STREQUAL "SHARED" ) )
EnsureLibraries(<YourTargetName> "${ADD_ADDITIONAL_LIBRARIES}" )
ENDIF ( ( WIN32 OR CYGWIN ) AND ( ${LIB_TYPE} STREQUAL "SHARED" ) )
Also, little hint, if you build libraries on Windows, allways use
shared. CMake creates the .lib files automatically in such a case.
kind regards
Roland
On Wed, Jun 26, 2013 at 1:31 PM, Graham Bloice
<graham.bloice@xxxxxxxxxxxxx> wrote:
> On 26 June 2013 11:29, Graham Bloice <graham.bloice@xxxxxxxxxxxxx> wrote:
>>
>> On 26 June 2013 11:07, Roland Knall <rknall@xxxxxxxxx> wrote:
>>>
>>> Hi
>>>
>>> GLOB and GLOB_RECURSE should normally only catch files, not
>>> directories. (As noted on
>>> http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:file)
>>>
>>
>> Several references found on Google imply that it did return directories as
>> well despite the docs. My empirical testing seems to show that it doesn't.
>>
>>>
>>> You should look for ares.h. From the returned path you could deduct
>>> the directory path with STRING.
>>
>>
>> I'll try this next.
>>>
>>>
>>> Alternativly you could look on google for Findcares.cmake, which will
>>> get you some matches for other people, who attempted the same thing.
>>> From there you can either take their hints or create your own version.
>>>
>>
>> I'm hacking in the Wireshark copy of that file and all the ones I find on
>> Google are similar. None of them cater for Windows oddities.
>>
>>> More problematic is finding the library. But you could either use the
>>> built-in function find_library or use the cmake module
>>> FindPackageHandleStandardArgs.cmake (Description in the header of the
>>> file).
>>>
>>
>> Again, it appears that there is nothing in standard CMake to handle the
>> Windows oddities. There is an existing bug/enhancement for CMake to add
>> VPATHS to find_path et al to cater for the version in the path but it hasn't
>> been progressed since 2010.
>>
>> My plan was to work out the path under $(PROJECT_LIB_DIR ) for each
>> library and supply that as HINTS to find_path and find_library.
>>
>> I believe there's another issue as well, on Windows the linker requires
>> access to the import library for linking (e.g.
>> $(PROJECT_LIB_DIR)/c-ares-1.9.1-1-win32ws/lib/libcares-2.lib) and then the
>> dll should be copied to the output directory to load at run-time
>> ($(PROJECT_LIB_DIR)/c-ares-1.9.1-1-win32ws/lib/libcares-2.dll).
>>
>> I haven't worked out how CMake handles the import library yet.
>>
>>> Allways try to use as many built-in commands as possible, because even
>>> something simple as a little foreach and some paths you set may lead
>>> to cross-compilation mayhem in the future.
>>
>>
>> I think all the Windows oddities will have to be wrapped in IF(WIN32) or
>> similar to prevent other breaking CMake on other platforms.
>>
>>>
>
> This now works for finding the include path, it appears FILE(GLOB) does
> locate dirs, where I was going wrong was with round braces instead of curly
> braces when using CMake vars:
>
> IF (WIN32)
> SET(PROJECT_LIB_DIR "W:/Wireshark/wireshark-win32-libs")
> FILE(GLOB subdir "${PROJECT_LIB_DIR}/*")
> FOREACH(dir ${subdir})
> IF(IS_DIRECTORY ${dir})
> IF("${dir}" MATCHES ".*/c-ares-.*")
> MESSAGE("Found c-ares: ${dir}")
> SET(CARES_HINTS ${dir})
> ENDIF()
> ENDIF()
> ENDFOREACH()
> ENDIF(WIN32)
>
> FIND_PATH(CARES_INCLUDE_DIR ares.h HINTS "${CARES_HINTS}/include")
>
> Note that I still had to add the "/include" suffix to FIND_PATH. I thought
> CMake did that automagically. Shouldn't be too hard to make a macro
> function to do the search for an aribitrary library string.
>
> Next is fixing the FIND_LIBRARY. I assume it's looking for the import
> library to supply to the linker, in this case the library name is
> .../lib/libcares-2.lib which is different from the unix name and has a
> version number and a different extension.
>
> Graham
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
Attachment:
EnsureLibraries.cmake
Description: Binary data
Attachment:
EnsureLibrariesRunner.cmake
Description: Binary data