Towards a stable release and an SDK

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

milliams wrote:

I've been seeing those warnings on my own builds in Linux since the beginning so I'm not sure why they weren't showing up before. I would say that it's correct that they do show up now even though they're not that useful. It doesn't look like it's possible to explicitly disable just those warnings though.

I've renamed all the files called glew.c to glew.cpp. I'm not sure if this has any other knock-on effects as to how the compiler treats the files but it seems to work ok, and it's only for the examples anyway. It's either that or we find a way to make CMake pass different command line parameters to different files. This is untested on Linux, so let's see if the warnings are gone tonight.

milliams wrote:

I did notice the failing AmbientOcclusionCalculator test and I saw that you changed the first of the comparisons to be equal to the Linux result. Now it seems to be complaining about the second one. On my Linux box (similar GCC version but everything else is different) I get the same results as the build box so it seems consistent on Linux.

Yes, so apparently the second one passed the first time. I'm not sure it's entirely consistant even on one machine. I've updated it anyway, and we'll see if it fails again. And at some point I'll try to make it match on Windows.

milliams · **Posted:** Sun Jun 19, 2011 11:35 am

David Williams wrote:

I've renamed all the files called glew.c to glew.cpp. I'm not sure if this has any other knock-on effects as to how the compiler treats the files but it seems to work ok, and it's only for the examples anyway. It's either that or we find a way to make CMake pass different command line parameters to different files. This is untested on Linux, so let's see if the warnings are gone tonight.

It looks like it's worked locally here as well as on the build box. I imagine that they were being built in 'C++ mode' anyway so there shouldn't be any change in behaviour.

David Williams wrote:

Yes, so apparently the second one passed the first time. I'm not sure it's entirely consistant even on one machine. I've updated it anyway, and we'll see if it fails again. And at some point I'll try to make it match on Windows.

I think that it will run through the QCOMPAREs in order so that if the first one fails then the rests aren't run and the test fails. So it was only once the first QCOMPARE was 'fixed' that the second one was run and then failed. I've set all of them to be equal to my local box since it seemed to be matching with the build box so hopefully it will pass tonight.

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

milliams wrote:

I think that it will run through the QCOMPAREs in order so that if the first one fails then the rests aren't run and the test fails.

Ah, ok, I didn't realise it worked like that. But that would explain the behaviour we've been seeing. Let's see how it does tonight.

On a related note, I tried to build PolyVox on a new laptop today which didn't have Qt installed, and so it couldn't find the Qt test module. When this happens it requires you to define a variable to prevent the tests being built, but maybe this could be defined automatically if the test module isn't found?

Firefly · **Joined:** Tue Jul 05, 2011 5:38 am **Posts:** 5

What are the actual steps to get this building on Windows?

I've installed latest CMake and I change into the library directory and run this command:

cmake -DCMAKE_INSTALL_PREFIX:PATH=c:\polytmp ..

I then run "make install" from same directory but get compilation errors in AStarPathfinder.cpp : error: expected ',' or '...' before '>' token

Am I doing it all wrong?

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

Firstly I would recommend you use the last stable snapshot (maybe you already are) rather than the latest from Git as some refactoring is going on at the moment.

My setup is I use the empty 'build' folder which already exists in root folder of the source distribution. I launch a Visual Studio command prompt, cd into the build directory, and run 'cmake ..'. I then open the generated Visual Studio solution and build from there.

I have a feeling that you need to build through Visual Studio rather than just by running 'make' from the command line. I think someone had this problem before though I didn't look into it. So you might need to provide the right generator to CMake (maybe through the -g switch?) if it doesn't find it automatically.

If it doesn't work, please post the errors in full.

Firefly · **Joined:** Tue Jul 05, 2011 5:38 am **Posts:** 5

I tried what you said but I'm still having problems. I started up a Visual Studio command prompt and ran 'cmake ..' but it didn't generate a VS solution, it instead appears to have made Makefiles. I then looked at specifying the generator but Visual Studio doesn't show up as an available generator when looking at the cmake help ('cmake --help').

I have cygwin installed so I'm thinking maybe somehow it's interfering with cmake?

This is the output when running cmake: http://pastebin.com/urhYQsuK

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

Yep, looks like it's picking up GCC. If I run 'cmake -h' I get the following:

Code:

.
.
.
Generators

The following generators are available on this platform:
  Borland Makefiles           = Generates Borland makefiles.
  MSYS Makefiles              = Generates MSYS makefiles.
  MinGW Makefiles             = Generates a make file for use with
                                mingw32-make.
  NMake Makefiles             = Generates NMake makefiles.
  NMake Makefiles JOM         = Generates JOM makefiles.
  Unix Makefiles              = Generates standard UNIX makefiles.
  Visual Studio 10            = Generates Visual Studio 10 project files.
  Visual Studio 10 Win64      = Generates Visual Studio 10 Win64 project
                                files.
  Visual Studio 6             = Generates Visual Studio 6 project files.
  Visual Studio 7             = Generates Visual Studio .NET 2002 project
                                files.
  Visual Studio 7 .NET 2003   = Generates Visual Studio .NET 2003 project
                                files.
  Visual Studio 8 2005        = Generates Visual Studio .NET 2005 project
                                files.
  Visual Studio 8 2005 Win64  = Generates Visual Studio .NET 2005 Win64
                                project files.
  Visual Studio 9 2008        = Generates Visual Studio 9 2008 project files.
  Visual Studio 9 2008 Win64  = Generates Visual Studio 9 2008 Win64 project
                                files.
  Watcom WMake                = Generates Watcom WMake makefiles.
  CodeBlocks - MinGW Makefiles= Generates CodeBlocks project files.
  CodeBlocks - NMake Makefiles= Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles = Generates CodeBlocks project files.
  Eclipse CDT4 - MinGW Makefiles
                              = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - NMake Makefiles
                              = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles
                              = Generates Eclipse CDT 4.0 project files.
.
.
.

Note that I don't actually have most of those compilers installed. Do you get something similar? I think you need to run something like

Code:

cmake .. -G "Visual Studio 10"

With the quotes as well. The '..' might go at the end, I'm not sure.

Towards a stable release and an SDK

Who is online