On Aug 1, 2014, at 2:00 AM, Peter Wu <peter@xxxxxxxxxxxxx> wrote:
> On Thursday 31 July 2014 16:40:53 Guy Harris wrote:
>> On Jul 31, 2014, at 3:11 PM, Peter Wu <peter@xxxxxxxxxxxxx> wrote:
> [..]
>>> Oh my, that filesystem.c code is really ugly and relying on a lot of
>>> assumptions. Why does it need to distinguish build dirs from other dirs in
>>> the first place?
>>
>> So that you can just type "./wireshark" or "./tshark" after you've done a
>> build, and have it Just Work, rather than having to install Wireshark or
>> TShark before you can run it. Note that we run TShark to generate some man
>> pages.
>
> The binaries themselves already Just Work(tm) without libtool because CMake
> sets RPATH.
Presumably by "the binaries themselves already Just Work" you mean "the binaries are, at least, capable of finding the relevant shared libraries, even if the code *in* those binaries, and the shared libraries in question, fails to find the data files such as RADIUS dictionaries, DIAMETER dictionaries, FIX field description files, etc., and thus doesn't Just Work", as that's a more precise description of the situation.
I.e., the problem has nothing to do with finding the *shared libraries*, it has to to with finding the *data files*.
For autotools builds, the data files *are* found, without any need for the user to specify anything themselves, for in-tree builds; the code determines the location of those data files based on the location of the executable image, so that it picks up the data files from the source tree.
For out-of-tree builds, however, that obviously doesn't work, as the executable isn't in the source tree.
> I would like to get rid of the WIRESHARK_RUN_FROM_BUILD_DIRECTORY if
> possible, not treating it specially and instead rely on environment variables
> to configure stuff.
As long as the user has to set precisely none of those environment variables themselves when running from the build directory, that would be OK.
If the user has to set any of them himself or herself, that no longer Just Works.
> Setting WIRESHARK_DATA_DIR should work without surprises
Note that the source tree doesn't have exactly the same layout as the directory tree of global configuration files; if we're not going to have the code know whether we're running from the build directory or not, the build process will probably have to collect all the files that would be installed as global configuration files (RADIUS dictionaries, DIAMETER dictionaries, Lua files, AUTHOR-SHORT file, etc., etc.) and copy them to a tree with that layout, with WIRESHARK_DATA_DIR pointed at the root of that tree.
> (this behavior is not even documented, only root/setuid should have this special behavior).
The fact that we ignore environment variables when run with special privileges isn't documented? Yes, it should be, although we should perhaps extend the notion of "special privileges" to include, for example, process capabilities.
>>> rundir=$(cd "$(dirname "$0")" && pwd)
>>> #rundir=$(dirname "$(readlink -f "$0")")
>>> export WIRESHARK_DATA_DIR=$rundir
>>> export WIRESHARK_PLUGIN_DIR=$rundir
Either
1) those would need to set those to the *source* directory, *and* the code would need to know that some files (such as init.lua) aren't in their normal locations (i.e., that we're running from the build directory)
or
2) the build process will need to make a copy of the data files, in the same fashion that installation does, and the script should point to the copied tree.
> If this approach is taken, an option must be added to support the use of GDB /
> valgrind.
.../otool/etc., along the lines of "./libtool --mode=execute {command} {program}".
