Wireshark-dev: Re: [Wireshark-dev] Ethereal to Wireshark issues
From: Peter Johansson <Peter.xc.Johansson@xxxxxxxxxxxx>
Date: Wed, 26 Jul 2006 15:57:30 +0200
One have to remember though to run nmake with the install-deps build target after every recompilation of the source (for any change you make). Otherwise Wireshark is started with the old compiled code. I can't remember the amount of times I have been trying to debug my code and it just does not seem to be executing what I just rewrote.

Why is the install-deps build target not a default operation when building on Windows? Is there a reason for it?

/ Regards, Peter

Steve Grinwis wrote:
Hey all,

	Using the install-deps build target fixed the problem.  It works
like a charm (well... it loads the plugin).  Now the only problems that
I have are ones with my code.   And I can deal with my code.   Thanks so
much!

-Steve

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Jaap Keuter
Sent: Wednesday, July 26, 2006 5:11 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Ethereal to Wireshark issues

Hi,

Isn't that why we have the install-deps build target?

Thanx,
Jaap

On Wed, 26 Jul 2006, Graham Bloice wrote:

I rebuilt Wireshark to see if I could find any errors in the build.
I
came across a few things.

<SNIP>

        rm -rf 0.99.2


It actually removes the 0.99.2 directory after it builds the
plug-ins.
And the whole "Cannot find module" error looks very similar to the
error
I get at run time.   Any thoughts?


On windows, you can't run Wireshark from the build directory.  The
makefiles
temporarily create an environment that can run the exe to generate
some docs
etc., then destroy it.

I have a batch file that I run after building that copies all the
dll's and
exe's to the appropriate places that a previous standard install has
created
and I then run the app from there.

You can also install nsis and make an installer, but that takes a lot
longer
than just copying the executables.

Graham