VS 2017 support

[Monkeychops]

Has anyone managed to get T3D to build with VS2017? I foolishly broke my VS 2015 because I ran out of disk space and it seems the VS 2017 compiler has issues with the code.

[chriscalef]

It worked out of the box for me. After my VS2015 foolishly broke itself beyond all hope of recovery, for no apparent reason. :-\

[Monkeychops]

I get a ton of errors like this when I try to use the vs2017 compiler:

error C2938: 'MaybeSelfEnabled' : Failed to specialize alias template

[JeffR]

Did you just upgrade an existing project by opening it in 2017, or did you have cmake generate a new project for it?

Also, can you post up the full error log on pastebin or something? May have some additional clues, but I can say I didn't have any issues with it when I ran the 2017 RC before.

[Azaezel]

For clarity, what engine versions? 3.9, 3.10, devhead?

[Monkeychops]

I'm trying to build the dev branch (https://github.com/GarageGames/Torque3D/tree/development) with VS 2017 final release and the latest CMake 3.8.2.

I'm using the "Visual Studio 15 2017 Win64" generator with a clean BaseGame template. It was working before when I used the VS 2015 generator but it will not let me do that now since I broke my VS 2015 installation.

Error looks like this:

[chriscalef]

OMFG, well, this is perhaps unrelated news, but I just fired up my VS 2017 and found it taking a dump very similar to the one taken by my 2015 install. Way to go, Microsoft. Looks like I'm back on the full OS reinstall path, sigh.

But anyway, good luck Monkeychops!

[Azaezel]

Got a similar report from @Timmy https://hastebin.com/asureduyeq.tex looks like it might be a sign of the new VS version handling variadics in a subtly different (or more paranoid) manner, though we did run across https://connect.microsoft.com/VisualStudio/Feedback/Details/2173198

[chriscalef]

Ya know, I never thought I'd say this, but my recent round of excruciating Visual Studio pain has caused me to ask: Waaay back in the day, my first paid gig at Garage Games, before Visual Studio express version even existed, was to put together a build system involving Eclipse and I don't remember what compiler, but it was a free way to build Torque without buying Visual Studio. We dropped that chain of development like a hot potato as soon as VS became free, because it was a serious pain in the butt to maintain a secondary build method when there was already a free option.

But... fast forward to today, does anyone have any suggestions for a potential windows environment build method/compiler that might circumvent this trauma? I love all the bells and whistles but this round of BS has got me seriously doubting the wisdom of being 100% dependent on Visual Studio for my windows build. I'm half afraid that I'm going to pave and reinstall only to find the same thing popping up in a few weeks, given how all of my recent problems have manifested entirely on their own.

EDIT: (I don't even care about the IDE at this point, I'd go back to using Emacs if I had a good way to command line compile for Windows. I suppose I should try reinstalling the OS at least once before I give up but... dang, Microsoft!)

[Monkeychops]

I quite like the CMake > VS workflow with the tooling etc.

Installing VS 2017 is nowhere near as painful as previous versions, they have made the installer a lot more lightweight and faster, and it is easy to repair individual components if something goes wrong. The only problem is, the compiler seems to be more strict. I think if we fix whatever it doesn't like, it should work well enough in future. Only trouble is, I don't really get what is wrong or how to fix it. :shock:

[Jason Campbell]

Ya know, I never thought I'd say this, but my recent round of excruciating Visual Studio pain has caused me to ask: Waaay back in the day, my first paid gig at Garage Games, before Visual Studio express version even existed, was to put together a build system involving Eclipse and I don't remember what compiler, but it was a free way to build Torque without buying Visual Studio. We dropped that chain of development like a hot potato as soon as VS became free, because it was a serious pain in the butt to maintain a secondary build method when there was already a free option.

But... fast forward to today, does anyone have any suggestions for a potential windows environment build method/compiler that might circumvent this trauma? I love all the bells and whistles but this round of BS has got me seriously doubting the wisdom of being 100% dependent on Visual Studio for my windows build. I'm half afraid that I'm going to pave and reinstall only to find the same thing popping up in a few weeks, given how all of my recent problems have manifested entirely on their own.

EDIT: (I don't even care about the IDE at this point, I'd go back to using Emacs if I had a good way to command line compile for Windows. I suppose I should try reinstalling the OS at least once before I give up but... dang, Microsoft!)

 

Even when you get VS working again, you could try out code:blocks with gcc a try, as an alt. Im Linux only so I can only attest for that but after I figured it out I really like it. It very simplistic but I enjoy the work flow of it.

[chriscalef]

Thanks, I didn't know code::blocks had a windows version.

Re: being linux only, do you by any chance have a cross compile system worked out for windows builds? I haven't put any time into it yet but if I knew I had that reliably nailed, with no new bugs added, I'd probably just reboot to Ubuntu and stay there. :-)

[Jason Campbell]

I do not have a cross-compile setup quite yet, however, it is on my to-do list. Even though, I have left Windows behind for good, I realize others cannot(yet?), so I have been researching it. I think the answer is the mingw compiler which does cross platform compiling. I will attempt to delve into it this weekend a bit. I would love to get it working with my current project and I would like to help you to get away from Microsoft.

[JeffR]

Yeah, feel free to look at other tools to see what works. More options that work well is always good.

For the topic at hand, I found this:

https://developercommunity.visualstudio.com/content/problem/25618/visual-studio-2017-template-issues.html

Looks like it's an issue that slipped in(as I didn't have any issues with 2017RC) that'll get fixed in the service pack, going off what the one post says. I'm looking into the hotfix the one person suggests now, and if it works, can see about getting that rolled in in the event of using this particular version.

[elfprince13]

Now that Visual Studio supports alternate compilers (i.e. Clang), I think it would be in everyone's best interest to drop the VC++ compiler (I don't care for the VS IDE either, but that's personal preference - the VC++ compiler is objectively bad).

[Azaezel]

Have to say given the choice, I'd prefer to preserve, well, The Choice. Kinda half the reason for cmake with it's drop down to begin with.

[JeffR]

So, I posted on the one issue thread and got a reply indicating that it should be in the next update. Apparently the compiler and IDE teams do updates at different rates(because why keep it simple). So I'll continue keeping my eye on this. If the next big update comes out and it's still not there, I'mma go hounding.

[Timmy]

Yeah they have taken their merry time to fix it :/ Anyways as to dropping support for VC++, it is the most widely used compiler in existence, dropping support for it would be the dumbest thing ever done.

[JeffR]

I mean, for a long-term goal, I'm reaaaaally hoping MS themselves drop it and swap to clang. But for the near-term, I agree, a bit pre-emptive to whole-hog over to it just yet.

[Happenstance]

The fix for this was supposed to be in the VS2017 15.3 release but the preview version is still tripping up over the 'MaybeSelfEnabled' template in engineFunctions.h. Anyone know of a workaround?

[HeadClot]

I would like to chime in on this.

Look into Kdevelop. It is a really nice IDE.

My 2 Cents on the matter.

[Bloodknight]

Solution to this problem was added to the repository a few weeks back, posting here in case this is the first thread people find looking for solutions

http://forums.torque3d.org/viewtopic.php?f=2&t=1046

[Timmy]

Solution to this problem was added to the repository a few weeks back, posting here in case this is the first thread people find looking for solutions

http://forums.torque3d.org/viewtopic.php?f=2&t=1046

 

Thanks blood, I totally forgot to post in here that i fixed that up.

[andijh92]

Hi,

using clang, rtags and msys2 would also be cool.

* msys2 is similar to arch gnu/linux but on top of windows without posix emulation like cygwin. msys2 can also be used to install torque3d dependencies like sdl, openal, (maybe clang) ...

* rtags is a source code navigation tool. it is better in parsing c++ code than cscope, gnu global ,... because it uses directly a clang library. it can be used with emacs, vim and sublime text.

[JeffR]

Hey guys, just to get everyone up to speed on it. We noted an issue with the latest release of 2017, version 15.3.

Ended up being that they made some changes that ended up introducing unreliable/regressive behavior with heavy usage of offsetof(). Given that we use that to interface the script engine with the C++ classes, it meant T3D - mostly in debug, though it apparently was happening passingly in release as well - could get a stack overflow crash. We tracked it down and rolled a hotfix for it into devhead: https://github.com/GarageGames/Torque3D/pull/2072 so VS15.3 plays nicely again.

But just as a heads up if you're updating VS to 15.3, make sure to nab at least that fix, if not latest from devhead to resolve the issue.