On 08/01/14 13:54, Guy Harris wrote:
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.
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).
