Wireshark-dev: Re: [Wireshark-dev] CMake for Windows
From: Roland Knall <rknall@xxxxxxxxx>
Date: Wed, 26 Jun 2013 13:52:54 +0200
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
- References:
- [Wireshark-dev] CMake for Windows
- From: Graham Bloice
- Re: [Wireshark-dev] CMake for Windows
- From: Roland Knall
- Re: [Wireshark-dev] CMake for Windows
- From: Graham Bloice
- Re: [Wireshark-dev] CMake for Windows
- From: Roland Knall
- Re: [Wireshark-dev] CMake for Windows
- From: Graham Bloice
- Re: [Wireshark-dev] CMake for Windows
- From: Graham Bloice
- [Wireshark-dev] CMake for Windows
- Prev by Date: Re: [Wireshark-dev] CMake for Windows
- Next by Date: Re: [Wireshark-dev] packet_win.c still broken
- Previous by thread: Re: [Wireshark-dev] CMake for Windows
- Next by thread: Re: [Wireshark-dev] [Wireshark-commits] rev 50097: /trunk/epan/ /trunk/epan/dissectors/: Makefile.am Makefile.common /trunk/epan/: Makefile.am
- Index(es):
- Get Wireshark
- Download
- Code of Conduct