On 7/31/14 2:19 PM, Graham Bloice wrote:
> On 31 July 2014 22:14, Graham Bloice <graham.bloice@xxxxxxxxxxxxx
> <mailto:graham.bloice@xxxxxxxxxxxxx>> wrote:
>
> On 31 July 2014 17:34, Gerald Combs <gerald@xxxxxxxxxxxxx
> <mailto:gerald@xxxxxxxxxxxxx>> wrote:
>
> On 7/31/14 6:08 AM, Graham Bloice wrote:
> > On 31 July 2014 11:42, Bálint Réczey <balint@xxxxxxxxxxxxxxx
> <mailto:balint@xxxxxxxxxxxxxxx>
> > <mailto:balint@xxxxxxxxxxxxxxx
> <mailto:balint@xxxxxxxxxxxxxxx>>> wrote:
> >
> > +1 for dropping autotools in favor of CMake. CMake already
> covers all
> > my use cases.
>
> Same here except for Windows. I've been doing most of my Qt
> development
> using Qt Creator + CMake. It doesn't have all the conveniences of Qt
> Creator + QMake but it works well enough.
>
> > I also support dropping nmake, but since I'm not building
> on Windows I
> > can't tell if CMake is complete enough.
> >
> > Not yet. Working on it though.
>
> I added "msbuild" steps to the Windows buildslaves after the "cmake"
> steps. The 32-bit build succeeds although I haven't tried
> running it.
> The 64-bit build passes /MACHINE:X86 to the linker which then fails.
>
>
> The buildslaves are failing to build the solution. I think the
> arguments to the msbuild step should be modified to be "msbuild"
> "/m" "/p:Configuration=RelWithDebInfo" "Wireshark.sln".
Done.
> And the x86 buildslave CMake still isn't locating a viable Python
> Interpreter.
The machine has the official Python 2.6 installed in c:\Python26 and
Cygwin's Python 2.7 installed in c:\cygwin\usr\bin. According to
http://www.cmake.org/pipermail/cmake/2010-February/035404.html
CMake looks for numbered Pythons executables (python2.7, python2.6, ...)
before looking for the plain executable. In our case this means it's
finding Cygwin's Python before the official version. The version
detection then fails for some reason. I'm going to try installing the
official Python 2.7. Hopefully it will be found before Cygwin's.