On Aug 1, 2014, at 2:00 AM, Peter Wu <pe...@lekensteyn.nl> wrote:
> On Thursday 31 July 2014 16:40:53 Guy Harris wrote:
>> On Jul 31, 2014, at 3:11 PM, Peter Wu <pe...@lekensteyn.nl> 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}".
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
