Wireshark · Wireshark-dev: Re: [Wireshark-dev] Building on Windows with CMake: Status and help needed

[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

On 8 October 2013 00:22, Joerg Mayer <jmayer@xxxxxxxxx> wrote:

> > > This is undoubtedly about the fact that Makefile.nmake copies lots of
> > > DLLs and etc to a separate "run" directory.
> > >
> > > The exe's won't run from the build dir on Windows.
> > >
> > > See install_all: target in Makefile.nmake (top-level)
> > >
> > > ...
> > > # "install-all" will copy all files needed to run Wireshark/Tshark
> > > # to the INSTALL_DIR, so you can run/debug Wireshark/Tshark from there.
> > > install-all: install-generated-files
> > > ...
> >
> > Dependency Walker (www.dependencywalker.com) is pretty useful for
> > finding dependent DLLs.
> >
> >
> I forgot to mention that when I mentioned "dumpbin /dependants" earlier.

I think I've found an easier solution to run inside the source tree:
Just the the PATH variable to all the libdirs. So far I have only tried
this manually but I've finally managed to run capinfos (and get the
usage output :-)
If I find the time I'll add automatic PATH modification tomorrow evening,
the idea is something like:
check whether path has already been modified. if not:
set( ENV{PATH} $ENV{PATH} ${CMAKE_BINARY_DIR}/lib <list> <of> <lib> <dirs> )

Feel free to beat me to it ;-)

Good night

You got there with the idea before me.  I was thinking last night about the DLL search path (http://msdn.microsoft.com/en-us/library/7d83bc18.aspx) used by windows, and like you think that just modifying the path will do the job.  Can that path extension be "exported" to the calling shell so that a dev can build and then run from the same command prompt?

This actually leads to another bugbear of mine.  All the third party libraries are extracted to separate directories with random locations for their includes, import libraries (.lib) and DLL's that really complicates the windows build.

I think it would be a good idea, when reworking the third party lib downloader, to arrange for these three components of the third party libs to all be in a consistent place, e.g. all headers under .../include/somelib/, all import libs under .../lib and all binaries under .../bin, similar to the organisation of these items on some other well known platforms.  This means less messing around with paths to all these things in CMake.

Graham