Wireshark · Wireshark-dev: Re: [Wireshark-dev] Status Cmake Win32 support

[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

On 12 October 2013 23:22, Joerg Mayer <jmayer@xxxxxxxxx> wrote:

On Sat, Oct 12, 2013 at 07:58:45PM +0100, Graham Bloice wrote:
> >
> > - Are there other platforms that would benefit from something similar to
> >   what I did with the setenv.bat script?
>
>
> The setenv.bat (I hope that is the file you're referring to) doesn't work
> with a MSVC2010 solution, as the paths to the libraries directory is wrong,
> it has ...\builddir\lib, it should be ...\builddir\Debug\lib, and the bin
> directory is wrong, it has \msvc2010\bin, it should be
> ...\builddir\Debug\bin.  note that the Debug portion of these paths will
> vary depending on the type of build done, Debug is the default, there are
> also; MinSizeRel, Release and RelWithDebInfo.  I think there will be a
> CMake variable for that somewhere.

My whole setup has only been tested with '-G "NMake Makefiles"' in that
environment it's using \lib and \bin directly. I'd be interested to know
where that \Debug in the path comes from. cmake has something that I have
not used so far, which is called CONFIGURATIONS. But unless configurations
are used I don't know where that Debug is supposed to come from. Do you
experience this only with the VS generator or with the nmake generator as
well?
Once I know where this comes from I have no problem of adding \${whatever}
to the paths.
Which reminds me: Configurations are something we should also add to the
build at some time ;)

 

It is definitely a configuration option.  I think CMake builds a single configuration when building for Makefiles and multi-configuration when building for Visual Studio.  CMAKE_BUILD_TYPE defines the configuration to be built when configuring a single configuration project and CMAKE_CFG_INTDIR specifies the actual configuration in use when building the project.  In msbuild this is set via a `/p:Configuration=xxxx` switch, in the VS IDE it's a drop down.

 

> I've also noted that sometimes the linker has a malformed option on it:
> '/LARGEADDRESSAWARE;setargv.obj'.

Fixed in revision 52574 by removing both options. None seems to make a
difference on my system.

 

LARGEADDRESSAWARE allows a 32 bit process to use 3GB of RAM on a 64 bit OS that has sufficient RAM instead of the normal 2GB.  Very useful flag to set.