From dabbaaf4189b88ae76870f7724c07f458c1e8b17 Mon Sep 17 00:00:00 2001 From: Peter Wu Date: Sat, 28 Feb 2015 17:44:27 +0100 Subject: filesystem: Fix build dir detection when using cmake Fixes loading of plugins by detecting the build output directory of cmake. This requires a "CMakeCache.txt" file to be present in the parent directory (above run/). Change-Id: I297432cdcd0981646058410f3eadf5f73b5248c8 Reviewed-on: https://code.wireshark.org/review/7453 Petri-Dish: Peter Wu Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman --- README.cmake | 27 --------------------------- 1 file changed, 27 deletions(-) (limited to 'README.cmake') diff --git a/README.cmake b/README.cmake index 275ef4dd7e..5d798f5697 100644 --- a/README.cmake +++ b/README.cmake @@ -174,33 +174,6 @@ What needs to be done? appropriately for OS X. We currently use NSIS for the Windows installer but should probably use WiX instead. - Add support for cmake configurations. -- Automatically figure out if *shark is running from the build directory - (making WIRESHARK_RUN_FROM_BUILD_DIRECTORY unnecessary like it is with - autofoo). - Sadly: - - $ file run/qtshark - run/qtshark: Mach-O 64-bit x86_64 executable - - so what you're running from the build directory is the executable - itself. autofoo includes libtool in our case, so what you're running - from the build directory is a script that then runs the executable, - and the executable is in a .libs directory; the code that checks for - "running from the build directory?" checks for that. The actual - executable isn't supposed to be run directly - it's expected to be run - by the wrapper script and might not even work if run directly, as it - won't find the relevant shared libraries. - - We could perhaps check for the executable being in a "run" directory - instead, if the build drops it there. However, it's possible, at - least on OS X, to copy the executable to another directory and have - it run, so the guarantee that it's in a "run" directory is not as - strong. -- Get plugins loading when running *shark from the build directory. - That might involve handling ".libs" and "run" differently. The chance - that a random directory the executable was ultimately placed in would - be named "run" might also be a bit bigger than the chance that it's - named ".libs". - Get cross-compilation working (or ensure it does). It works with autofoo--and people use it. - Handle -DFORTIFY_SOURCE=2 appropriately. (Do a Web search for -- cgit v1.2.1