Page 1 of 1
visual studio 2017 build issues
Posted: 21 Sep 2017, 15:39
by dskiller1
I didnt see anything wrong with using the nuget, at lest it was working.
with the new way I run into problems.
for some reason the project doesnt have the third party folder including in the sln,
so it doesnt find glew and the other files.
I follow the direction for cmake. and still run into the problem
I redid everything and now for some reason cmake cant find phyfs, even though before it find it...
Re: visual studio 2017 build issues
Posted: 21 Sep 2017, 18:02
by Vincent
The provided sln doesn't work, it's there because someone complained that it was removed while it was used on some build bot.
What is the error message from cmake ? Did you pass -DCMAKE_TOOLCHAIN_FILE=... to cmake ?
For reference here is my CMakeSettings.json :
Code: Select all
{
// See https://go.microsoft.com//fwlink//?linkid=834763 for more information about this file.
"configurations": [
{
"name": "x86-Debug",
"generator": "Ninja",
"configurationType": "Debug",
"inheritEnvironments": [ "msvc_x86" ],
"buildRoot": "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\build\\${name}",
"cmakeCommandArgs": "-DCMAKE_TOOLCHAIN_FILE=C:\\Users\\vlj\\Documents\\GitHub\\vcpkg\\scripts\\buildsystems\\vcpkg.cmake",
"buildCommandArgs": "",
"ctestCommandArgs": ""
},
{
"name": "x86-Release",
"generator": "Ninja",
"configurationType": "RelWithDebInfo",
"inheritEnvironments": [ "msvc_x86" ],
"buildRoot": "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\build\\${name}",
"cmakeCommandArgs": "-DCMAKE_TOOLCHAIN_FILE=C:\\Users\\vlj\\Documents\\GitHub\\vcpkg\\scripts\\buildsystems\\vcpkg.cmake",
"buildCommandArgs": "-v",
"ctestCommandArgs": ""
},
{
"name": "x64-Debug",
"generator": "Ninja",
"configurationType" : "Debug",
"inheritEnvironments": [ "msvc_x64" ],
"buildRoot": "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\build\\${name}",
"cmakeCommandArgs": "",
"buildCommandArgs": "-v",
"ctestCommandArgs": ""
},
{
"name": "x64-Release",
"generator": "Ninja",
"configurationType" : "RelWithDebInfo",
"inheritEnvironments": [ "msvc_x64" ],
"buildRoot": "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\build\\${name}",
"cmakeCommandArgs": "",
"buildCommandArgs": "-v",
"ctestCommandArgs": ""
}
]
}
Re: visual studio 2017 build issues
Posted: 22 Sep 2017, 05:30
by dskiller1
well..
I got cmake working.
and it builds the exe and .dll files but when starting it shows cmd type screen and then error box stating the procdure entry point ?istransactionstarted@QJODevice@@QBE_NZ could not be located in the dynamic link library c:\qt\qt5.9.1\msvc2015\bin\qt5script.dll
Re: visual studio 2017 build issues
Posted: 23 Sep 2017, 10:43
by Vincent
Looks like an issue with qt, see
https://forum.qt.io/topic/26707/the-pro ... -library/9
Can you clean and then rebuild wz2100 ? Also check that Qt is in your path (especially check that you only have only one qt version installed)
Re: visual studio 2017 build issues
Posted: 28 Sep 2017, 08:08
by dskiller1
I have only the one qt installed.
I found out the debug version builds and runs.
but the release version doesnt.
qt paths
Path=C:\Qt\5.9.1\msvc2015\bin
QT5DIR=C:\Qt\5.9.1\msvc2015
Re: visual studio 2017 build issues
Posted: 02 Oct 2017, 13:48
by moltengear
Qt is not completely free now.
Constant problems with compilation.
Qt compulsively installs the development tool QtCreator.
But still, qt is good!
What do you think about the engine from Google?
https://developers.google.com/v8/
Re: visual studio 2017 build issues
Posted: 02 Oct 2017, 18:41
by NoQ
Replacing the javascript engine should be relatively easy, as long as it supports everything we need. I tried to mock up a quick proof-of-concept for replacing QScriptEngine with
v8-based QJSEngine at
viewtopic.php?f=35&t=11912#p130055 and even in this wrapper it seems suitable. Wasn't the biggest problem, so i never finished this experiment.
However, as far as i remember, we use Qt not only for scripts, but also for a few other things.
Re: visual studio 2017 build issues
Posted: 02 Oct 2017, 21:58
by Vincent
Would be nice to remove qt completly. As far as I know QString is included in every file to support Unicode, in lib/widget and in 2 files in src for widget support. However I don't know why : the UI doesn't have signal/slot support and the draw routine are reimplemented.
I'm in favor of removing QString for something more "standard" although I didn't find anything outstanding in this regard. There are couple of libs but I have no idea which one to pick. On the other hand Warzone doesn't really do any string manipulation, plain old std::string and std::wstring could be enough as long as we don't rely on parsing and can ensure that no Unicode character can be used in config file.
Removing qtgame is possible, I didn't try to build it with cmake.
Re: visual studio 2017 build issues
Posted: 03 Oct 2017, 05:52
by cybersphinx
Vincent wrote:can ensure that no Unicode character can be used in config file.
Can we? It contains gameName, mapName and playerName, I'd assume those do (and should) support unicode.
Re: visual studio 2017 build issues
Posted: 08 Oct 2017, 22:52
by Vincent
For what it worths I could remove qt signal/slot in lib/widgets with a couple line change without issues. I think it should be easy to keep qt contained to the script section then.
Re: visual studio 2017 build issues
Posted: 09 Oct 2017, 14:14
by Per
The new debug menu uses Qt for UI. (We could replace lib/widget with Qt's javascript-based UI rendering engine, actually. Been thinking about it, seems sensible, it is just a huge amount of work.)
I've been thinking the duktape engine would make a good replacement for QtScript. We have to change anyway, since Qt has deprecated QtScript and will remove it some day in the future.
Re: visual studio 2017 build issues
Posted: 17 Oct 2017, 22:23
by Vincent
For what it worth there is also Chakra-Core (the JS engine used in Edge) which is available in vcpkg (which means it's easy to support using cmake build system since the include and libraries are available out of the box). It performs apparently well depending on the benchmark used. V8 API is a lot nicer though in my opinion but building it and embedding it may be cumbersome.
Re: visual studio 2017 build issues
Posted: 18 Oct 2017, 01:23
by moltengear
There is another such js engine.
https://github.com/gfwilliams/tiny-js
I think that there is a need to create a wrapper in order to test different engines. This is for the future without hurting the project.
The concept of signals and slots loses its significance. Because the trend is to increase the processor cores from different manufacturers. Especially now!