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 <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>

diff --git a/README.cmake b/README.cmake
index 275ef4dd7ef61b446ea39c5b623a94e866974446..5d798f5697d90a0208f8a691e61dafea6316f2c3 100644 (file)
--- 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

diff --git a/wsutil/filesystem.c b/wsutil/filesystem.c
index b58654f6647caec9a399af59a0d8512fc378796c..87bf99b7ac38d9475b3eb9536bafaeb4431bbdde 100644 (file)
--- a/wsutil/filesystem.c
+++ b/wsutil/filesystem.c
@@ -717,9 +717,23 @@ DIAG_ON(pedantic)
                 if (!started_with_special_privs())
                     running_in_build_directory_flag = TRUE;
             }
+            else if (!started_with_special_privs()) {
+                /*
+                 * Check for the CMake output directory. As people may name
+                 * their directories "run" (really?), also check for the
+                 * CMakeCache.txt file before assuming a CMake output dir.
+                 */
+                if (strcmp(dir_end, "/run") == 0) {
+                    gchar *cmake_file;
+                    cmake_file = g_strdup_printf("%.*s/CMakeCache.txt",
+                                                 (int)(dir_end - prog_pathname),
+                                                 prog_pathname);
+                    if (file_exists(cmake_file))
+                        running_in_build_directory_flag = TRUE;
+                    g_free(cmake_file);
+                }
 #ifdef __APPLE__
-            else {
-                if (!started_with_special_privs()) {
+                if (!running_in_build_directory_flag) {
                     /*
                      * Scan up the path looking for a component
                      * named "Contents".  If we find it, we assume
@@ -761,8 +775,8 @@ DIAG_ON(pedantic)
                         p--;
                     }
                 }
-            }
 #endif
+            }
         }
 
         /*