Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] master 43a81b6: Add some information on
On 08/01/14 14:04, Evan Huus wrote:
On Fri, Aug 1, 2014 at 1:58 PM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx
<mailto:jeff.morriss.ws@xxxxxxxxx>> wrote:
On 08/01/14 13:54, Guy Harris wrote:
On Aug 1, 2014, at 2:00 AM, Peter Wu <peter@xxxxxxxxxxxxx
<mailto: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 <mailto: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.
Actually out-of-tree builds can find the data files in out-of-tree
builds due to another hack that I put in (bug 5664/r38070).
Well it's not finding all of them or the out-of-tree test suite would
work (right now it fails to find init.lua and the name-resolutions
settings, so those tests fail).
I posted fixes for the nameres failure (change 3334) and the wslua
failure (change 3337). The wslua failure wasn't because init.lua wasn't
being found (it was) it was because taps_wslua.c was empty in an
out-of-source-tree build.
