[Wireshark-dev] Windows build environment (was: Re: [Wireshark-commits] rev 52194: ...)

2013-09-25 Thread Gerald Combs
On 9/24/13 3:15 AM, Graham Bloice wrote:
 On 24 September 2013 10:49, Joerg Mayer jma...@loplof.de
 mailto:jma...@loplof.de wrote:
 
 On Tue, Sep 24, 2013 at 10:24:33AM +0100, Graham Bloice wrote:
  On 24 September 2013 10:17, Joerg Mayer jma...@loplof.de
 mailto:jma...@loplof.de wrote:
 
   On Mon, Sep 23, 2013 at 05:32:38PM -0700, Gerald Combs wrote:
Would it make things easier for either of you if you could get
 useful
answers from pkg-config on Windows?
  
   Sure! The problem to solve here is how to handle the different
 install
   places (not everyone will find c:\wireshark\ a convenient place
 where to
   put the Wireshark-winXX-libs directory). In my current cmake
 install I've
   created an (environment) variable to specify that base path.
   Apart from that: it would be helping because pkgconfig will
 allow us to
   get additional information like other required libs, compile
 flags etc.
  
  
  As Jorg says, the main issue right at the start is the location of
 stuff,
  does pkg-config give you that, or is it more oriented around how the
  package was built and configured?  I'm not at all familiar with
 pkg-config.
 
 It will provide paths, but also additional information required to
 bild a program
 with that lib.
 
 Here is an example:
 jmayer@egg:~ pkg-config --cflags gtk+-3.0
 -pthread -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0
 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0
 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo
 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0
 -I/usr/lib/glib-2.0/include -I/usr/include/harfbuzz
 -I/usr/include/freetype2 -I/usr/include/pixman-1
 -I/usr/include/libpng12 -I/usr/include/libpng15
 jmayer@egg:~ pkg-config --libs gtk+-3.0
 -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0
 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0
 -lglib-2.0
 If linking would require -L or other flags, they would be displayed
 as well.
 
 Is any of that useful for what we want to do on Windows?  I don't know.

pkg-config has a --msvc-syntax flag which generates output compatible
with Visual C++, so it's at least theoretically useful. In practice it's
a bit more complex. It looks like we'd have to come up with a path
naming convention for .pc file collections for each build configuration
(32-bit and 64-bit), then point pkg-config at the desired collection. We
could do this by setting environment variables ourselves or by using a
wrapper script.[1]

I was hoping that we could make pkg-config as easy to use out of the box
as it is on other systems but the deeper I dig the more complex it becomes.

  My proto-plan at the moment is that the env installer\updater
  (chocolatey??) will grab all the required bits and store them
 somewhere
  (possibly configurable by the user) and then provide that
 location(s) as a
  hint(s) to CMake (env var is too ephemeral for me, probably a
 file) which
  can then go and do its thing.
 
 The current windows build process seems to require
 set WIRESHARK_TARGET_PLATFORM=winXX
 so I added
 set WIRESHARK_BASE_DIR=c:/wireshark
 If you think a registry entry would be better: That's supported by cmake
 as well and would probably be a cleaner solution.

Chocolatey supports this approach with metapackages. E.g. a
wireshark.devenv metapackage could have dependencies for specific
versions of software libraries and less specific dependencies for things
like Python and Nasm. Libraries, DLLs, and headers would end up in
easy-to-find paths under %ChocolateyInstall%. I like this approach
better than pkg-config (although strictly speaking they aren't mutually
exclusive).

  I still prefer a file as its easier for folks to adjust (maybe easier
 to mess up).

Agreed.

[1]https://www.flameeyes.eu/autotools-mythbuster/pkgconfig/cross-compiling.html

___
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 build environment

2012-01-18 Thread Graham Bloice


 -Original Message-
 From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
 boun...@wireshark.org] On Behalf Of Andriy Beregovenko
 Sent: 17 January 2012 20:38
 To: wireshark-dev@wireshark.org
 Subject: Re: [Wireshark-dev] Windows build environment
 
 Hi Graham,
 
 On Mon, Jan 16, 2012 at 09:39:19AM -, Graham Bloice wrote:
 
 
   -Original Message-
   From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
   boun...@wireshark.org] On Behalf Of Andriy Beregovenko
   Sent: 13 January 2012 23:14
   To: wireshark-dev@wireshark.org
   Subject: Re: [Wireshark-dev] Windows build environment
  
   Hi Graham,
  
   Oh, this is very actual issue.
  
   My personal wishlist consist of two things:
   1. Generation of register.c must be completely reworked, cause most
   times
  I
   must wait about 15-20 minutes when recompiling sources; 2. Make
   CMake default for win-platform building is really good idea.
  
 
  Are you using a platform native build of python or the Cygwin version?
  A platform native build should faster.  When I've been doing intensive
  work on a single dissector I've commented out the bit of
  Makefile.nmake that generates register.c when it wasn't required.
 
 How I can detect this? I'm use windows-msi-installer from python.org.
 Version 2.7.2. Btw at compile time I get error in python script
works(another
 script, not that script that generate register.c)
 

Andriy,

The output of nmake -f Makefile.nmake verify_tools will tell you which
python you are using.  If you've installed Windows Python 2.7 into the
default directory it should be C:\Python27\python.exe.

config.nmake has some settings for which python to use, but if you leave
everything at the defaults it should pick up the Windows python
installation.

  As the generation of register.c uses Python across all platforms
  replacing it would require another cross platform solution, and as my
  guess is that the generation is I/O bound moving to a compiled rather
  than an interpreted solution may not improve things.
 Anyway, to compile wireshark you need to install many other more
 traditional tools, like bash and perl. Hence there are pocible much
faster
 replacement for python :) But, i think, this is more holywat theme then
 practical.
 

I would be very surprised to find Cygwin bash or perl faster than a native
Python, or even a Cygwin Python.  On my Win XP build VM, generating
register.c using windows Python 2.7 takes 6 seconds.



___
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 build environment

2012-01-18 Thread Andriy Beregovenko
Hi Graham,

On Wed, Jan 18, 2012 at 10:12:10AM -, Graham Bloice wrote:
 
 
  -Original Message-
  From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
  boun...@wireshark.org] On Behalf Of Andriy Beregovenko
  Sent: 17 January 2012 20:38
  To: wireshark-dev@wireshark.org
  Subject: Re: [Wireshark-dev] Windows build environment
  
  Hi Graham,
  
  On Mon, Jan 16, 2012 at 09:39:19AM -, Graham Bloice wrote:
  
  
-Original Message-
From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
boun...@wireshark.org] On Behalf Of Andriy Beregovenko
Sent: 13 January 2012 23:14
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] Windows build environment
   
Hi Graham,
   
Oh, this is very actual issue.
   
My personal wishlist consist of two things:
1. Generation of register.c must be completely reworked, cause most
times
   I
must wait about 15-20 minutes when recompiling sources; 2. Make
CMake default for win-platform building is really good idea.
   
  
   Are you using a platform native build of python or the Cygwin version?
   A platform native build should faster.  When I've been doing intensive
   work on a single dissector I've commented out the bit of
   Makefile.nmake that generates register.c when it wasn't required.
  
  How I can detect this? I'm use windows-msi-installer from python.org.
  Version 2.7.2. Btw at compile time I get error in python script
 works(another
  script, not that script that generate register.c)
  
 
 Andriy,
 
 The output of nmake -f Makefile.nmake verify_tools will tell you which
 python you are using.  If you've installed Windows Python 2.7 into the
 default directory it should be C:\Python27\python.exe.

[BSo I all the time use native python build :)
 
 config.nmake has some settings for which python to use, but if you leave
 everything at the defaults it should pick up the Windows python
 installation.
   As the generation of register.c uses Python across all platforms
   replacing it would require another cross platform solution, and as my
   guess is that the generation is I/O bound moving to a compiled rather
   than an interpreted solution may not improve things.
  Anyway, to compile wireshark you need to install many other more
  traditional tools, like bash and perl. Hence there are pocible much
 faster
  replacement for python :) But, i think, this is more holywat theme then
  practical.
  
 
 I would be very surprised to find Cygwin bash or perl faster than a native
 Python, or even a Cygwin Python.  On my Win XP build VM, generating
 register.c using windows Python 2.7 takes 6 seconds.

Somewhy, when REbuild is in progress, generating register.c takes mre
time. But, when I do clean build(I mean after distclean), register.c generates
in a few seconds.
 
 
 
 ___
 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

-- 
Best regards,
Andriy
0xBDDBDAE3


signature.asc
Description: Digital signature
___
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 build environment

2012-01-17 Thread Andriy Beregovenko
Hi Graham,

On Mon, Jan 16, 2012 at 09:39:19AM -, Graham Bloice wrote:
 
 
  -Original Message-
  From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
  boun...@wireshark.org] On Behalf Of Andriy Beregovenko
  Sent: 13 January 2012 23:14
  To: wireshark-dev@wireshark.org
  Subject: Re: [Wireshark-dev] Windows build environment
  
  Hi Graham,
  
  Oh, this is very actual issue.
  
  My personal wishlist consist of two things:
  1. Generation of register.c must be completely reworked, cause most times
 I
  must wait about 15-20 minutes when recompiling sources; 2. Make CMake
  default for win-platform building is really good idea.
  
 
 Are you using a platform native build of python or the Cygwin version?  A
 platform native build should faster.  When I've been doing intensive work on
 a single dissector I've commented out the bit of Makefile.nmake that
 generates register.c when it wasn't required.

How I can detect this? I'm use windows-msi-installer from python.org.
Version 2.7.2. Btw at compile time I get error in python script
works(another script, not that script that generate register.c)

 As the generation of register.c uses Python across all platforms replacing
 it would require another cross platform solution, and as my guess is that
 the generation is I/O bound moving to a compiled rather than an interpreted
 solution may not improve things.
Anyway, to compile wireshark you need to install many other more
traditional tools, like bash and perl. Hence there are pocible much faster
replacement for python :) But, i think, this is more holywat theme then
practical.
 
 
 ___
 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

-- 
Best regards,
Andriy
0xBDDBDAE3


signature.asc
Description: Digital signature
___
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 build environment

2012-01-17 Thread Andriy Beregovenko
Hi Graham,

Greate news!
I found my old notebook with WinXP x86_32, install to it MSVC2008EE, Python,
Cygwin. Download 1.6.5 sources, add my own dissector+update Makefile.common.
Run build, and no python fails happened... Also I was suprised, after
wireshark build done, I run it with sample dump for my dissecter and it not
crash at all... Another words, if I build on WinXP 32bit - result is fine,
but if I try to do same things on my Win7 64bit, build fails and result is
unusable... 

Developers, developers, developers... (c)

Time goes by, nothing has changed...

On Mon, Jan 16, 2012 at 09:39:19AM -, Graham Bloice wrote:
 
 
  -Original Message-
  From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
  boun...@wireshark.org] On Behalf Of Andriy Beregovenko
  Sent: 13 January 2012 23:14
  To: wireshark-dev@wireshark.org
  Subject: Re: [Wireshark-dev] Windows build environment
  
  Hi Graham,
  
  Oh, this is very actual issue.
  
  My personal wishlist consist of two things:
  1. Generation of register.c must be completely reworked, cause most times
 I
  must wait about 15-20 minutes when recompiling sources; 2. Make CMake
  default for win-platform building is really good idea.
  
 
 Are you using a platform native build of python or the Cygwin version?  A
 platform native build should faster.  When I've been doing intensive work on
 a single dissector I've commented out the bit of Makefile.nmake that
 generates register.c when it wasn't required.
 
 As the generation of register.c uses Python across all platforms replacing
 it would require another cross platform solution, and as my guess is that
 the generation is I/O bound moving to a compiled rather than an interpreted
 solution may not improve things.
 
 
 ___
 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

-- 
Best regards,
Andriy
0xBDDBDAE3


signature.asc
Description: Digital signature
___
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 build environment

2012-01-17 Thread Andriy Beregovenko
Hi wireshark-dev,

But this build fails on Win7 to work :)

On Wed, Jan 18, 2012 at 01:29:22AM +0200, Andriy Beregovenko wrote:
 Hi Graham,
 
 Greate news!
 I found my old notebook with WinXP x86_32, install to it MSVC2008EE, Python,
 Cygwin. Download 1.6.5 sources, add my own dissector+update Makefile.common.
 Run build, and no python fails happened... Also I was suprised, after
 wireshark build done, I run it with sample dump for my dissecter and it not
 crash at all... Another words, if I build on WinXP 32bit - result is fine,
 but if I try to do same things on my Win7 64bit, build fails and result is
 unusable... 
 
 Developers, developers, developers... (c)
 
 Time goes by, nothing has changed...
 
 On Mon, Jan 16, 2012 at 09:39:19AM -, Graham Bloice wrote:
  
  
   -Original Message-
   From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
   boun...@wireshark.org] On Behalf Of Andriy Beregovenko
   Sent: 13 January 2012 23:14
   To: wireshark-dev@wireshark.org
   Subject: Re: [Wireshark-dev] Windows build environment
   
   Hi Graham,
   
   Oh, this is very actual issue.
   
   My personal wishlist consist of two things:
   1. Generation of register.c must be completely reworked, cause most times
  I
   must wait about 15-20 minutes when recompiling sources; 2. Make CMake
   default for win-platform building is really good idea.
   
  
  Are you using a platform native build of python or the Cygwin version?  A
  platform native build should faster.  When I've been doing intensive work on
  a single dissector I've commented out the bit of Makefile.nmake that
  generates register.c when it wasn't required.
  
  As the generation of register.c uses Python across all platforms replacing
  it would require another cross platform solution, and as my guess is that
  the generation is I/O bound moving to a compiled rather than an interpreted
  solution may not improve things.
  
  
  ___
  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
 
 -- 
 Best regards,
 Andriy
 0xBDDBDAE3



 ___
 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


-- 
Best regards,
Andriy
0xBDDBDAE3


signature.asc
Description: Digital signature
___
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 build environment

2012-01-16 Thread Graham Bloice


 -Original Message-
 From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
 boun...@wireshark.org] On Behalf Of Andriy Beregovenko
 Sent: 13 January 2012 23:14
 To: wireshark-dev@wireshark.org
 Subject: Re: [Wireshark-dev] Windows build environment
 
 Hi Graham,
 
 Oh, this is very actual issue.
 
 My personal wishlist consist of two things:
 1. Generation of register.c must be completely reworked, cause most times
I
 must wait about 15-20 minutes when recompiling sources; 2. Make CMake
 default for win-platform building is really good idea.
 

Are you using a platform native build of python or the Cygwin version?  A
platform native build should faster.  When I've been doing intensive work on
a single dissector I've commented out the bit of Makefile.nmake that
generates register.c when it wasn't required.

As the generation of register.c uses Python across all platforms replacing
it would require another cross platform solution, and as my guess is that
the generation is I/O bound moving to a compiled rather than an interpreted
solution may not improve things.


___
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 build environment

2012-01-13 Thread Andriy Beregovenko
Hi Graham,

Oh, this is very actual issue.

My personal wishlist consist of two things:
1. Generation of register.c must be completely reworked, cause most times I
must wait about 15-20 minutes when recompiling sources;
2. Make CMake default for win-platform building is really good idea.

On Fri, Jan 06, 2012 at 03:46:52PM -, Graham Bloice wrote:
 Folks,
 
  
 
 This email was triggered by the recent win-setup.sh issue reported, but I?ve
 been thinking about the issues for a while.
 
  
 
 FWIW over the Xmas break I looked into reworking the windows build to remove 
 as
 many external dependencies (such as Cygwin) as possible.  I was using
 PowerShell to replace the bash bits.  We would still need Python and probably
 Perl as they are intrinsic to the build, and some gnuwin32 utilities such as
 bison and flex but I thought that the rest could be handled by PowerShell
 scripts.  Any extra executable (apart from Python and Perl) not normally found
 on a Windows machine could be bundled in a zip file similar to the way we
 handle the libs required.
 
  
 
 Does anyone see any value in this?
 
  
 
 I've also wondered about moving on from nmake and converting to MSBuild.  This
 is only usable from VS2008 or later though.  Any thoughts on that?
 
  
 
 And there is also CMake, does anyone use that for the windows build?
 
  
 
  
 
 --
 
 Regards,
 
  
 
 Graham Bloice
 

 ___
 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


-- 
Best regards,
Andriy
0xBDDBDAE3


signature.asc
Description: Digital signature
___
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 build environment

2012-01-12 Thread Graham Bloice


 -Original Message-
 From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
 boun...@wireshark.org] On Behalf Of Joerg Mayer
 Sent: 12 January 2012 00:19
 To: Developer support list for Wireshark
 Subject: Re: [Wireshark-dev] Windows build environment
 
 On Wed, Jan 11, 2012 at 11:23:21AM -, Graham Bloice wrote:
   On Jan 6, 2012, at 7:46 AM, Graham Bloice wrote:
  
I've also wondered about moving on from nmake and converting to
   MSBuild.  This is only usable from VS2008 or later though.  Any
   thoughts
  on
   that?
  
   If we do so, can we continue to have lists of source files in
  Makefile.common,
   rather than, say, having to duplicate such a list in other files
   (which developers might forget to do)?  Or, at least, can we
   automatically
  generate
   the relevant MSBuild files from files such as Makefile.common?
 
  Although I haven't investigated I would expect MSBuild to be able to
  absorb such input and make it useable, either directly or by a task to
  generate the required file.
 
 As an alternative: How about making building with cmake work for Windows?
 After that, maybe the following article has some clues:
 http://stackoverflow.com/questions/1459482/how-to-use-cmake-for-non-
 interactive-build-on-windows
 
 I'm willing to support anyone who is willing to tackle this, it's just
that I don't
 have a Windows system to do this on my own.
 

My initial motivation was more about reducing dependencies on stuff that
Windows folks don't normally have installed, e.g. Cygwin, and also to move
things forward a bit in terms of supported build technologies, although I
don't suppose nmake is going away anytime soon.

Last time I looked at CMake on Windows it didn't work for me, but I didn't
look too hard.  IIUC CMake is a Makefile generator, can it do all the
stuff we currently do in nmake which is a fair bit more than just working
out dependencies and compiling and linking the required modules?

CMake's ability to generate Visual Studio project files could be attractive
to some as well.


___
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 build environment

2012-01-11 Thread Guy Harris

On Jan 6, 2012, at 7:46 AM, Graham Bloice wrote:

 I've also wondered about moving on from nmake and converting to MSBuild.  
 This is only usable from VS2008 or later though.  Any thoughts on that?

If we do so, can we continue to have lists of source files in Makefile.common, 
rather than, say, having to duplicate such a list in other files (which 
developers might forget to do)?  Or, at least, can we automatically generate 
the relevant MSBuild files from files such as Makefile.common?
___
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 build environment

2012-01-11 Thread Graham Bloice


 -Original Message-
 From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
 boun...@wireshark.org] On Behalf Of Guy Harris
 Sent: 11 January 2012 10:59
 To: Developer support list for Wireshark
 Subject: Re: [Wireshark-dev] Windows build environment
 
 
 On Jan 6, 2012, at 7:46 AM, Graham Bloice wrote:
 
  I've also wondered about moving on from nmake and converting to
 MSBuild.  This is only usable from VS2008 or later though.  Any thoughts
on
 that?
 
 If we do so, can we continue to have lists of source files in
Makefile.common,
 rather than, say, having to duplicate such a list in other files (which
 developers might forget to do)?  Or, at least, can we automatically
generate
 the relevant MSBuild files from files such as Makefile.common?

Although I haven't investigated I would expect MSBuild to be able to absorb
such input and make it useable, either directly or by a task to generate the
required file.


___
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 build environment

2012-01-11 Thread Joerg Mayer
On Wed, Jan 11, 2012 at 11:23:21AM -, Graham Bloice wrote:
  On Jan 6, 2012, at 7:46 AM, Graham Bloice wrote:
  
   I've also wondered about moving on from nmake and converting to
  MSBuild.  This is only usable from VS2008 or later though.  Any thoughts
 on
  that?
  
  If we do so, can we continue to have lists of source files in
 Makefile.common,
  rather than, say, having to duplicate such a list in other files (which
  developers might forget to do)?  Or, at least, can we automatically
 generate
  the relevant MSBuild files from files such as Makefile.common?
 
 Although I haven't investigated I would expect MSBuild to be able to absorb
 such input and make it useable, either directly or by a task to generate the
 required file.

As an alternative: How about making building with cmake work for Windows?
After that, maybe the following article has some clues:
http://stackoverflow.com/questions/1459482/how-to-use-cmake-for-non-interactive-build-on-windows

I'm willing to support anyone who is willing to tackle this, it's just that
I don't have a Windows system to do this on my own.

Ciao
Joerg

-- 
Joerg Mayer   jma...@loplof.de
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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


[Wireshark-dev] Windows build environment

2012-01-06 Thread Graham Bloice
Folks,

 

This email was triggered by the recent win-setup.sh issue reported, but I've
been thinking about the issues for a while.

 

FWIW over the Xmas break I looked into reworking the windows build to remove
as many external dependencies (such as Cygwin) as possible.  I was using
PowerShell to replace the bash bits.  We would still need Python and
probably Perl as they are intrinsic to the build, and some gnuwin32
utilities such as bison and flex but I thought that the rest could be
handled by PowerShell scripts.  Any extra executable (apart from Python and
Perl) not normally found on a Windows machine could be bundled in a zip file
similar to the way we handle the libs required.

 

Does anyone see any value in this?

 

I've also wondered about moving on from nmake and converting to MSBuild.
This is only usable from VS2008 or later though.  Any thoughts on that?

 

And there is also CMake, does anyone use that for the windows build?

 

 

--

Regards,

 

Graham Bloice

___
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

[Wireshark-dev] Windows build environment changes

2008-08-05 Thread Gerald Combs
I just set the default MSVC_VARIANT in config.nmake to MSVC2008 in
order to test that compiler on the Windows buildslave.  If it works
we can start using Visual C++ 2008 for official builds in the trunk.

Also, a new tag was created in wireshark-win32-libs yesterday. You'll
have to run nmake -f makefile.nmake setup next time you update SVN
(which you should now be warned about).

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] Windows build environment changes

2008-08-05 Thread Luis EG Ontanon
Does that mean that I just need to install the tools (MSVC2008+cygwin)
do a checkout, make setup, and make all with no need anymore to modify
any files?

\Lego

On Tue, Aug 5, 2008 at 7:13 PM, Gerald Combs [EMAIL PROTECTED] wrote:
 I just set the default MSVC_VARIANT in config.nmake to MSVC2008 in
 order to test that compiler on the Windows buildslave.  If it works
 we can start using Visual C++ 2008 for official builds in the trunk.

 Also, a new tag was created in wireshark-win32-libs yesterday. You'll
 have to run nmake -f makefile.nmake setup next time you update SVN
 (which you should now be warned about).

 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 https://wireshark.org/mailman/listinfo/wireshark-dev




-- 
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] Windows build environment changes

2008-08-05 Thread Sake Blok
Are plugins compiled with MSVC2008EE compatible with (official) wireshark 
versions compiled with MSVC2008?


Sake

- Original Message - 
From: Gerald Combs [EMAIL PROTECTED]
To: wireshark-dev@wireshark.org
Sent: Tuesday, August 05, 2008 7:13 PM
Subject: [Wireshark-dev] Windows build environment changes


I just set the default MSVC_VARIANT in config.nmake to MSVC2008 in
 order to test that compiler on the Windows buildslave.  If it works
 we can start using Visual C++ 2008 for official builds in the trunk.

 Also, a new tag was created in wireshark-win32-libs yesterday. You'll
 have to run nmake -f makefile.nmake setup next time you update SVN
 (which you should now be warned about).

 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 https://wireshark.org/mailman/listinfo/wireshark-dev

 


___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] Windows build environment changes

2008-08-05 Thread Gerald Combs
Question 32 in the Visual Studio Express FAQ
(http://www.microsoft.com/express/support/faq/) hints that it's possible:

  Does Visual C++ 2008 Express include the optimizing compiler?

  Yes, Visual C++ 2008 Express Edition includes the same core optimizing
  compiler that will be included with all other Visual Studio 2008
  editions. Some new expanded optimization features, including Profile
  Guided Optimizations, will be available only in the Standard and above
  editions of Visual Studio 2008.

I don't know if anyone has actually tried it, however.

On Tue, 5 Aug 2008 19:45:14 +0200, Sake Blok [EMAIL PROTECTED] wrote:
 Are plugins compiled with MSVC2008EE compatible with (official) wireshark
 versions compiled with MSVC2008?
 
 
 Sake
 
 - Original Message -
 From: Gerald Combs [EMAIL PROTECTED]
 To: wireshark-dev@wireshark.org
 Sent: Tuesday, August 05, 2008 7:13 PM
 Subject: [Wireshark-dev] Windows build environment changes
 
 
I just set the default MSVC_VARIANT in config.nmake to MSVC2008 in
 order to test that compiler on the Windows buildslave.  If it works
 we can start using Visual C++ 2008 for official builds in the trunk.

 Also, a new tag was created in wireshark-win32-libs yesterday. You'll
 have to run nmake -f makefile.nmake setup next time you update SVN
 (which you should now be warned about).

 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 https://wireshark.org/mailman/listinfo/wireshark-dev


 
 
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 https://wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] Windows build environment changes

2008-08-05 Thread Nathan Jennings
Using VS 2008 Pro:

I updated to svn 25939 and did nmake setup/distclean. I have 
config.nmake pulling in Wpd_Pack automatically for capturing (i.e. I'm 
not referencing my local winpcap copy).

I'm getting farther than I was a week or so ago: I can now use the file 
open dialog, but when I try to open a capture file, I get the generic MS 
crash dialog with:

AppName: wireshark.exe   AppVer: 1.0.99.0   ModName: msvcr90.dll
ModVer: 9.0.21022.8  Offset: 0002f9bb

Any manual changes needed on my part to tweak the build for this to work?

Thanks, -Nathan


 - Original Message -
 From: Gerald Combs [EMAIL PROTECTED]
 To: wireshark-dev@wireshark.org
 Sent: Tuesday, August 05, 2008 7:13 PM
 Subject: [Wireshark-dev] Windows build environment changes


 I just set the default MSVC_VARIANT in config.nmake to MSVC2008 in
 order to test that compiler on the Windows buildslave.  If it works
 we can start using Visual C++ 2008 for official builds in the trunk.

 Also, a new tag was created in wireshark-win32-libs yesterday. You'll
 have to run nmake -f makefile.nmake setup next time you update SVN
 (which you should now be warned about).

 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 https://wireshark.org/mailman/listinfo/wireshark-dev



___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev