Re: [Wireshark-dev] Windows CMake, multiple copies of libffi-6.dll

2015-07-20 Thread Pascal Quantin
2015-07-18 14:59 GMT+02:00 Graham Bloice graham.blo...@trihedral.com:


 Windows CMake always copies libffi-6.dll into the runtime directory,
 because it's found in two places in the support libraries, gnutls and
 gtk2.  The version from gnutls is copied first, then overwritten by the
 gtk2 version, then on the next build the same happens again. because both
 copies are triggered if the file is different.

 Unfortunately, although the files are different sizes, neither has any
 resources embedded indicating version or build numbers to be able to
 determine which one is best.

 Does anyone know which one we should be using?  Currently the gtk2 one is
 going out in builds, so seems to be OK.


Hi Graham,

as I added the gnutls package to the repository after Gerald added the GTK+
2.24.23 bundle, I would have considered that the former has the latest
version (as it was the one available on OBS servers by that time). But has
the exported symbols seem to be the same, it does not seem to matter much
(and as you said it just seems to *work fine* right now). Maybe it was just
compiled with a different compiler version or set of options. I see that
OBS is still on version 3.0.13 which was released in 2013, so this is most
likely the same version.

Pascal.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Windows cmake

2014-06-09 Thread Graham Bloice
On 5 June 2014 10:00, Graham Bloice graham.blo...@trihedral.com wrote:

 On 5 June 2014 07:18, Joerg Mayer jma...@loplof.de wrote:

 Hello (at least Graham),

 I'd like to get as far with the cmake on Windows stuff as possible during
 Sharkfest I thought we might as well start early ;-)

 What do we need to address in the cmake build system to be able to propose
 getting rid of the current nmake based Windows build system completely?

 One thing that needs to be addressed is the build setup:
 Currently parts of the setup (downloading, installing) are done by a
 script.
 Other parts like deciding which versions to use are done by make setup.
 Yet other parts are done when compiling wireshark (like compiling
 portaudio).
 Some are not done by anything in the setup/build process but have to be
 done
 manually (like fixing include files for some environments).

 So at least we need to
 a) create a list of what needs to be addressed exactly and
 b) decide how to do it (my personal approach would be to add all this to
 the existing setup script - but I'm not really familiar with all that
 Windows
 stuff).



 Somewhere on the list (last Oct\Nov ??) I posed a message with my list of
 things to do, however even the mighty Google can't find it.  I might be
 misremembering though.  I'll look for it later on tonight.

 We have also had previous discussions about the setup script and using
 alternative Windows package management systems e.g. Coapp or Chocolatey to
 run the downloads.  I think there are 3 phases to this though:

1. Creating\checking the build environment, i.e.
downloading\installing\updating all required libraries and tools and
checking the build env is sane.
2. Running CMake to produce the solution\nmake files for the installed
build env.  This might involve running the is build env sane script as a
prereq.  Some configuration items are defined by the build environment so
can be taken into account by CMake.
3. Using the toolchain with the CMake generated artefacts to produce a
build.  Some configuration items are defined by the sources (e.g. version
number, or build type, release, debug etc.) so the toolchain has to ensure
these are processed correctly.

 I would dearly like to remove Cygwin from the equation, switching to
 Gnuwin32 for things such as flex and bison, and PowerShell (or Python or
 CMake builtins) for general scripting tasks.  Even more contentious would
 be to remove the need for Perl, and use Python as the cross-platform script
 tool as using two script tools involves an extra download for Windows and
 it seems that Python is currently more essential to the build system (and
 I don't like Perl ;-) ).



The previous message I referred to is listed at the bottom of
http://www.wireshark.org/lists/wireshark-dev/201312/msg5.html

Now I've found it, I should update it.

1.  Copy build artifacts (and 3rd party dlls etc.) to a directory for
running (as per nmake).  Almost like install.  Note that the exact location
of the build artifacts depends on the type of build actually made (debug,
release etc.).

Currently we have setpath, which does work, but I don't like the way it
extends your path each time.  Also I found windeployqt that will copy all
required QT DLL's just by passing it your executable.

2.  Fix the generation of the manifext files (in progress GMB), and include
in build (use SED to produce .manifest from .manifest.in), should go into
correct intermediate build dir (e.g. wireshark.dir\Release).  Note needs to
know processor architecture, so maybe should be a prebuild custom command
for each target).

Still in progress, as in nothing done.

3.  Fix the generation of the .rc files (in progress GMB), and include in
build (use SED to produce .rc from .rc.in), should go into correct
intermediate build dir (e.g. wireshark.dir\Release).  Note associated .ico
and .manifest.

Still in progress, as in nothing done.

4.  Fix the use of zlib, so that zlib is built by CMake and doesn't require
nmake build first.
5.  Fix PortAudio.
6.  Fix CMake to find a working pkg-config.exe (only found in gtk2\bin at
the moment, missing from gtk3), currently manualy copied to build dir
(along with intl.dll and libglib-2.0-0.dll)

Doesn't seem to be needed now, and we only do GTK2 for windows.  To be
confirmed.

7.  Fix qtshark use its own .rc file (not done in nmake either)
8.  Fix build of plugins.
9.  Fix build of executables that use WTAP_PLUGIN_SOURCES.


--
Graham
___
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

Re: [Wireshark-dev] Windows cmake

2014-06-05 Thread Graham Bloice
On 5 June 2014 07:18, Joerg Mayer jma...@loplof.de wrote:

 Hello (at least Graham),

 I'd like to get as far with the cmake on Windows stuff as possible during
 Sharkfest I thought we might as well start early ;-)

 What do we need to address in the cmake build system to be able to propose
 getting rid of the current nmake based Windows build system completely?

 One thing that needs to be addressed is the build setup:
 Currently parts of the setup (downloading, installing) are done by a
 script.
 Other parts like deciding which versions to use are done by make setup.
 Yet other parts are done when compiling wireshark (like compiling
 portaudio).
 Some are not done by anything in the setup/build process but have to be
 done
 manually (like fixing include files for some environments).

 So at least we need to
 a) create a list of what needs to be addressed exactly and
 b) decide how to do it (my personal approach would be to add all this to
 the existing setup script - but I'm not really familiar with all that
 Windows
 stuff).



Somewhere on the list (last Oct\Nov ??) I posed a message with my list of
things to do, however even the mighty Google can't find it.  I might be
misremembering though.  I'll look for it later on tonight.

We have also had previous discussions about the setup script and using
alternative Windows package management systems e.g. Coapp or Chocolatey to
run the downloads.  I think there are 3 phases to this though:

   1. Creating\checking the build environment, i.e.
   downloading\installing\updating all required libraries and tools and
   checking the build env is sane.
   2. Running CMake to produce the solution\nmake files for the installed
   build env.  This might involve running the is build env sane script as a
   prereq.  Some configuration items are defined by the build environment so
   can be taken into account by CMake.
   3. Using the toolchain with the CMake generated artefacts to produce a
   build.  Some configuration items are defined by the sources (e.g. version
   number, or build type, release, debug etc.) so the toolchain has to ensure
   these are processed correctly.

I would dearly like to remove Cygwin from the equation, switching to
Gnuwin32 for things such as flex and bison, and PowerShell (or Python or
CMake builtins) for general scripting tasks.  Even more contentious would
be to remove the need for Perl, and use Python as the cross-platform script
tool as using two script tools involves an extra download for Windows and
it seems that Python is currently more essential to the build system (and
I don't like Perl ;-) ).
___
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