MSVC 2015 support

[ruby0x1]

Just making a note here for reference while I look into it - MSVC 2015 needs some changes to work.

The VS140COMNTOOLS variable is used for 2015, but isn't referenced in the msvc-setup.bat files.

[madrazo]

Hi. It's already there (3356a27), but its missing in msvc64-setup.bat

[ruby0x1]

Right sorry, that's what I meant to come back and note, I was intending to look into it but didn't get around to my Windows machine.

We should test 2015 for other potential problems and compatibility with the prebuilt libs.

@hughsando
The current haxelib release just throws an error about not finding MSVC with 2015, so a haxelib release would be necessary for users to use it. From what I understand 2015 is now properly released, at least from the MS website where you can download it. I've had a few users running into this error already :)

[hughsando]

I have been meaning to find time to test this myself. Does the git version
of hxcpp work with msvc15 as far as you know?

It should be pretty easy to do a release to solve this issue.

On Sat, Jul 25, 2015 at 3:27 AM, Sven Bergström notifications@github.com
wrote:

Right sorry, that's what I meant to come back and note, I was intending to
look into it but didn't get around to my Windows machine.

@hughsando https://github.com/hughsando
The current haxelib release just throws an error about not finding MSVC
with 2015, so a haxelib release would be necessary for users to use it.
From what I understand 2015 is now properly released, at least from the MS
website where you can download it. I've had a few users running into this
error already :)

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

[madrazo]

Hi. The issue I have found is when compiling (openfl) as "static", all the libs had to be recompiled with vs2015 (in my case I had to recompile the hxcpp/project libs and nme-dev)

[madrazo]

Also this small fix if someone wants to recompile OpenAL (now not used) haxenme/nme-dev#5

[hughsando]

This is a tricky one, since now msvc 2015 can't be made compatible with
2013 when static linking in any way.
This leaves the option of switching completely over to 2015, or to not
provide any static libraries directly, but have a way such that they are
compiled once on each developers machine.
I am leaning towards the second option if it can be made relatively
painless.

On Fri, Aug 7, 2015 at 9:24 PM, Carlos Madrazo notifications@github.com
wrote:

Also this small fix if someone wants to recompile OpenAL (now not used)
haxenme/nme-dev#5 haxenme/nme-dev#5

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

[madrazo]

Maybe they can be saved with a different name or directory and use ${MSVC_VER} or another flag to differentiate them?

[ruby0x1]

@hughsando any word on an updated release? I am now well past one user a day failing to work on stable releases. With the fact that VS installer takes forever to install/uninstall its extremely unfortunate to be told that the install you just spent an hour waiting for is actually invalid and you need to start over.

Please, let me know if there are things I can help to speed up a hxcpp stable release.

[hughsando]

I implemented 'magic_libs' a little while ago:
https://github.com/HaxeFoundation/hxcpp/blob/master/toolchain/haxe-target.xml#L160-L168

This should solve the problem by compiling the library code on the
developers machine using their current compiler/settings.
You may not be getting this logic depending on how you handle static
libraries in your tool, but it you "import hxcpp.StaticStd" it should be
handled for you.

Is something not working, or is it that you just need a new release?

On Wed, Sep 23, 2015 at 7:52 AM, Sven Bergström notifications@github.com
wrote:

@hughsando https://github.com/hughsando any word on an updated release?
I am now well past one user a day failing to work on stable releases. With
the fact that VS installer takes forever to install/uninstall its extremely
unfortunate to be told that the install you just spent an hour waiting for
is actually invalid and you need to start over.

Please, let me know if there are things I can help to speed up a hxcpp
stable release.

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

[ruby0x1]

From what I understand, MSVC 2015 does not work out of the box, as with 2013/2012/2010. This is leading users into a mess, and often MSVC un/re/installs break things further by messing up the environment variables.

The fixes mentioned above are needed for the normal use of hxcpp for VS 2015.
However It's been 2 months since VS 2015 was released (and this issue filed).
The new release would include the above mentioned fixes to the build setup, which solves this problem.

re: static libs:
Since the last release was in may, I assume the magic libs being 8 days old won't solve anything for users yet - even though I am using hxcpp static libs.

That, and there are numerous other important fixes as well - like 500+ lines of warnings that GCC is still spewing since then as well :)

[hughsando]

I guess then I am asking if you think the current version on
http://nmehost.com/hxcpp/ is what you are after

On Thu, Sep 24, 2015 at 3:38 PM, Sven Bergström notifications@github.com
wrote:

From what I understand, MSVC 2015 does not work out of the box, as with
2013/2012/2010. This is leading users into a mess, and often MSVC
un/re/installs break things further by messing up the environment variables.

The fixes mentioned above are needed for the normal use of hxcpp for VS
2015.
However It's been 2 months since VS 2015 was released (and this issue
filed).
The new release would include the above mentioned fixes to the build
setup, which solves this problem.

re: static libs:
Since the last release was in may, I assume the magic libs being 8 days
old won't solve anything for users yet - even though I am using hxcpp
static libs.

That, and there are numerous other important fixes as well - like 500+
lines of warnings that GCC is still spewing since then as well :)

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

[ruby0x1]

Is there a reason that a 4 month+ time window is not time for a release yet?

I know haxe 3.3.0 is around the corner, if that is the case maybe we could use more communication on timing.

My concern is that we are getting back to months and months of waiting for hxcpp releases like 2012~2013 and it's disruptive to growth, but it's directly affecting the user experience on multiple platforms.

This is amplified by the fact that Windows 10, El Capitan, iOS 9, and more platform changes are already out, and right around the corner. The longer we wait the more behind the users get, and the more changes are required, leading to even longer release cycles.

So, what are we waiting on?

[hughsando]

Maybe I did not make myself clear. I intend to do a release this weekend,
and was wondering if the current dev version solves your problems, or if
something else needs to be done.

On Thu, Sep 24, 2015 at 4:36 PM, Sven Bergström notifications@github.com
wrote:

Is there a reason that a 4 month+ time window is not time for a release
yet?

I know haxe 3.3.0 is around the corner, if that is the case maybe we could
use more communication on timing.

My concern is that we are getting back to months and months of waiting for
hxcpp releases like 2012~2013 and it's disruptive to growth.

This is amplified by the fact that Windows 10, El Capitan, iOS 9, and more
platform changes are already out, and right around the corner. The longer
we wait the more behind the users get, and the more changes are required,
leading to even longer release cycles.

So, what are we waiting on?

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

[ruby0x1]

I'll test anything you need to me, not just MSVC related, you can grab me any time on slack as well.

I'll report back soon, thanks @hughsando

[ruby0x1]

Since updating to latest hxcpp release (yay!), I have a fresh install of VS2015 only on Windows 10, the following error is reported;

This seems to be a regression, as 64 bit builds have been working fine all along.

Error: 64bit is not autmatically supported for this version of VC. Set HXCPP_MSVC_CUSTOM and manually configure
 the executable, library and include paths                                                                     
Error: Error: 64bit is not autmatically supported for this version of VC. Set HXCPP_MSVC_CUSTOM and manually co
nfigure the executable, library and include paths                                                              

[hughsando]

So something may have changed in the latest, or there could be a bug in
hxcpp.
The condition is reasonably easy to see in toolchain/msvc64-setup.bat
Either the variable name has changed (VS140COMNTOOLS ?) or
the vcvarsx86_amd64.bat bat file name has moved. If you can work out which
one, the setup script should be reasonably easy to add a new section to.
I had a thing where I had to manually start the pdbserver - I think this is
a bug in msvc, so maybe they have moved some stuff around to fix it.
It is also possible that the 64bit support has been moved to a premium
version or is a separate download or similar.

On Thu, Oct 1, 2015 at 7:30 AM, Sven Bergström notifications@github.com
wrote:

Since updating to latest hxcpp release (yay!), I have a fresh install of
VS2015 only on Windows 10, the following error is reported;

This seems to be a regression, as 64 bit builds have been working fine all
along.

Error: 64bit is not autmatically supported for this version of VC. Set HXCPP_MSVC_CUSTOM and manually configure
the executable, library and include paths
Error: Error: 64bit is not autmatically supported for this version of VC. Set HXCPP_MSVC_CUSTOM and manually co
nfigure the executable, library and include paths

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

[ruby0x1]

2015 is still the full featured version, they got rid of that with the community editions (thankfully).

How about this comment, seems relevant #259 (comment)

I'll have a look.

[hughsando]

I missed that fact that it is a windows 10 issue - I should be able to get this reproduced.
As for libraries, I'm still thinking about doing away with pre-compiled static libs in general. hxcpp no longer needs them for vs2015, so it becomes something like an nme issue. I could probably add a vs2015 lib directory to at least give to option of supporting pre compiled libraries. Something like waxe takes ages to compile - but also the download is huge so it is not clear what the best solution is.

[hughsando]

So it seems to be working for me on win10 - any chance you can try the bat file directly for a hint about what might be going wrong?

[ruby0x1]

I can give more verbose info from the hxcpp parts and such.
Are you also on a clean install of 2015?
If you had previous working versions,
or maybe even a preconfigured hxcpp_config.xml it could hide this ootb error

[hughsando]

Yes, virgin 2015 install on top of fresh windows10 upgrade yesterday.

On Sat, Oct 3, 2015 at 12:10 AM, Sven Bergström notifications@github.com
wrote:

I can give more verbose info from the hxcpp parts and such.
Are you also on a clean install of 2015?
If you had previous working versions,
or maybe even a preconfigured hxcpp_config.xml it could hide this ootb
error

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

[jgranick]

I just heard about the "-19" naming. I believe it would be ideal perhaps to keep the same name for dynamic linking, and to work up a solution for user builds of static linked builds

We will have the same problem with mingw32, or other variations of compilers.

Lime does not include static binaries, the user needs to build these or use dynamic linking

[hughsando]

I have been meaning to do a post about the "-19" stuff, but I have been
putting out fires.
Basically, it is like a separate architecture (-arm64 etc) in that it goes
in the "Windows" or "Windows64" directory but has a suffix. There is one
complication though, and that is when you create an ndll, you don't add the
suffix. This is because neko will always look for the name without the
suffix, and ndlls created with one compiler should work with another
compiler.
Mingw gets around this because it uses ".a" not ".lib" so it gets a
different suffix for free.
The solution is LIBEXTRA has been split in two : HX_LINK_SUFFIX and
HX_TARGET_SUFFIX
When you link (-llibXYZ) you should use the HX_LINK_SUFFIX, when you
create, you should use HX_TARGET_SUFFIX
If you want to maintain compatibility with older hxcpp installs, you can
check to see if these exist, and use LIBEXTRA if they do not - just means
you will get "-19.ndll" files if you use vc2015. ie, you probably need the
latest hxcpp to build vc2015 ndlls.
The solution of not shipping static libs at all I think is going to be
easiest (and maybe no ndlls either), just did not quite make it into the
release.

On Thu, Oct 8, 2015 at 1:02 AM, Joshua Granick notifications@github.com
wrote:

I just heard about the "-19" naming. I believe it would be ideal perhaps
the keep the same for dynamic linking, and to work up a solution for user
builds of static linked builds

We will have the same problem with mingw32, or other variations of
compilers.

Lime does not include static binaries, the user needs to build these or
use dynamic linking

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

[tienery]

I've experienced (as well as others as I have searched the openfl forums regarding the same issue) what is presumably a Visual Studio conflict in versions of cl.exe to build Haxe projects, causing the following error to occur:

Process creation failure: cl.exe

Now as far as the toolchain in hxcpp is concerned, if either Visual Studio 2013 or 2015 is installed, it will use the compiler found in version 14.0 of the IDE. However, if both 2013 and 2015 is installed, this results in the above error.

Installing 2015 started causing the error, and uninstalling removed the error. I suspect if I uninstalled 2013 instead of 2015, that this would result in hxcpp using the 2015 version of the compiler. Perhaps hxcpp should add a clear distinguishment between the versions so that this error is resolved, and then I can install 2015 without the Haxe compiler complaining that it can't open the process?

[jgranick]

I'm a little late to this discussion, but I think there should be no
suffix.

If I use an old Android NDK, or a new one, I will likely have different
GCC versions, and may lose linking support when trying to link static
libraries of different versions. It seems like the compatibility of static
object files is usually sensitive to being similar compiler versions,
regardless of the platform.

The "-19" prefix has been causing trouble for users with new versions of
MSVC, we'll try and work a solution up using HX_LINK_SUFFIX (if available)
but I think it would make more sense to remove this entirely

On Wed, 07 Oct 2015 18:09:41 -0700, Hugh Sanderson
notifications@github.com wrote:

I have been meaning to do a post about the "-19" stuff, but I have been
putting out fires.
Basically, it is like a separate architecture (-arm64 etc) in that it
goes
in the "Windows" or "Windows64" directory but has a suffix. There is one
complication though, and that is when you create an ndll, you don't add
the
suffix. This is because neko will always look for the name without the
suffix, and ndlls created with one compiler should work with another
compiler.
Mingw gets around this because it uses ".a" not ".lib" so it gets a
different suffix for free.
The solution is LIBEXTRA has been split in two : HX_LINK_SUFFIX and
HX_TARGET_SUFFIX
When you link (-llibXYZ) you should use the HX_LINK_SUFFIX, when you
create, you should use HX_TARGET_SUFFIX
If you want to maintain compatibility with older hxcpp installs, you can
check to see if these exist, and use LIBEXTRA if they do not - just means
you will get "-19.ndll" files if you use vc2015. ie, you probably need
the
latest hxcpp to build vc2015 ndlls.
The solution of not shipping static libs at all I think is going to be
easiest (and maybe no ndlls either), just did not quite make it into the
release.

On Thu, Oct 8, 2015 at 1:02 AM, Joshua Granick notifications@github.com
wrote:

I just heard about the "-19" naming. I believe it would be ideal perhaps
the keep the same for dynamic linking, and to work up a solution for
user
builds of static linked builds

We will have the same problem with mingw32, or other variations of
compilers.

Lime does not include static binaries, the user needs to build these or
use dynamic linking

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

—
Reply to this email directly or view it on GitHub.

[NemoStein]

@tienery The only VS I have installed is VS2015 Comunnity on my Windows 10, still, I keep getting the Process creation failure: cl.exe error...

Is there any workaround?

Edit: Installing the VS2010 Express through haxelib run lime setup windows did NOT solved the problem, but I can't uninstall the VS2015 to test

[tienery]

I suspect it's because hxcpp doesn't support MS 2015 yet. I would uninstall it, and install 2013 instead, or any other earlier version. I think lowest common denominator, hxcpp must pick the latest version of the compiler to use, even if it's unsupported.

[NemoStein]

@tienery Sadly, this is my main developer machine... Going back to VS2013 will probably break my current projects, and I'm too afraid of this risk...

[ruby0x1]

If you read this thread it IS supported: The error comes from the fact that cl.exe is not found in your path. Most often this comes from the fact that MSVC has defined an environment variable that HXCPP can detect but has not correctly configured the PATH.

I have also been trying to figure out why this happens - on many cases a clean install of 2015 just works without problems. SOMETIMES it installs when hxcpp can't even detect MSVC (when msvc doesn't correctly configure the ENV var) and SOMETIMES it makes the variable but cl.exe is not found in the path.

The problem lies with the configuration of the system that hxcpp relies on:

• VS140COMNTOOLS - 2015
• VS120COMNTOOLS - 2013

If it can find this var, hxcpp assumes that the path is correct, and assumes cl.exe will be found. This error comes from this assumption not being true.

One suggested work around is to run your commands from inside the VS Command Line Prompt because it configures it's environment - but hxcpp runs this environment (or attempts to) automatically when VS is configured correctly.

You don't need to uninstall 2015 and use 2013, you just have to figure out why this state is inconsistent.

Here's the hxcpp part - you can try explicitly configuring it from your user folder .hxcpp_config.xml file, using something like <setenv name="HXCPP_MSVC" value="..."/>

[NemoStein]

@underscorediscovery Ok, let's break this thing down...

If I compile through the VS Command Prompt it works correctly (as you pointed out).
The VS140COMNTOOLS path variable is there, and pointing to my VS2015/common7/tools folder (as expected).
If I run the msvc-setup.bat in the hxcpp toolchain it calls the vsvars32.bat in the VS folder correctly (added echo in vsvars32.bat to be sure).
But, running the HaXe compiler after calling the msvc-setup.bat (in the same prompt window) doesn't work.
The cl.exe isn't found anywhere outside the VS Command Prompt.
Setting the <setenv /> in my .hxcpp_config.xml changes nothing, even if I set the <set name="NO_AUTO_MSVC" value="1" />

You said that I "... have to figure out why this state is inconsistent.", but I don't think I understand what you mean.
Any ideas?

Edit:
After 5hs I finally managed to make it work by simply reinstalling VS2015 and checking the Visual C++ option in the Programming Languages group. (Was I that silly?)

[hughsando]

I wonder if it is to do with which user and which permissions installed the
compiler.

If you set the environment variable "HXCPP_VERBOSE" then you will get some
more information, like:
...
Using default windows compiler : MSVC

• Parsing include: c:/Users/Hugh/dev/hxcpp/toolchain/finish-setup.xml
  Using msvc cl version 19
  ...
  Or maybe something else if it goes wrong.

On Sat, Feb 27, 2016 at 5:47 AM, NemoStein notifications@github.com wrote:

@underscorediscovery https://github.com/underscorediscovery Ok, let's
break this thing down...

If I compile through the VS Command Prompt it works correctly (as you
pointed out).
The VS140COMNTOOLS path variable is there, and pointing to my
VS2015/common7/tools folder (as expected).
If I run the msvc-setup.bat in the hxcpp toolchain it calls the
vsvars32.bat in the VS folder correctly (added echo in vsvars32.bat
to be sure).
But, running the HaXe compiler after calling the msvc-setup.bat (in the
same prompt window) doesn't work.
The cl.exe isn't found anywhere outside the VS Command Prompt.

You said that I "... have to figure out why this state is inconsistent.",
but I don't think I understand what you mean.
Any ideas?

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

[hughsando]

MSVC 2015 I think is well enough supported.
The process creation issue was, I assume, from missing cl.exe so is a legitimate error. I'm not sure I can get a better error message like "missing cl.exe - try reinstalling", but I will know next time some one asks.

The -19 suffix will not longer be an issue because the next version of haxe/hxcpp will not use static libraries.

[ghost]

Hello guys, have you problem with Visual Studio 2015 Community, right?

just use -vs14 example lime build windows -vs14
-vs14 means Visual Studio 14 = Visual Studio 2015

PS: Don't forget to copy netfx_core and netfx_extended into Net Frameworks 4.5 and 4.6 for fix Because I have checked Netfx Setup verifier - If you forget to copy both mzz files from Net Frameworks 4.0 because newest net frameworks didn't add mzz of Net Frameworks 4.0 cause it gets failure of Net Frameworks 4.0

If you use Windows 7 SP 1 than you make sure cleaned full-fresh net frameworks installations
Please make sure clean use Dotnetfx cleanup all net frameworks if they have failure of setups..

1. Unpack net frameworks 4.0 into backup for latest net frameworks copy-and-past.
2. Install complete with Net Frameworks 4.0 If Net Frameworks failed to install like rolling back
   You need uninstall all redisturbatable Visual C++ 2008, 2010 and possible 2012 but I don't know.than you check CCleaner all registry errors to fix.. Install again. if it doesn't work than you use administrated command type 1. RGB9RAST_(ARCH).msi, 2. netfx_core_(ARCH).msi extui=1 and 3. netfx_extended_(ARCH).msi extui=1 than you need to restart Windows 7. and continue ...
3. Unpack Net Frameworks 4.5 to netfx_45 and copy from net framework 4.0 netfx_core.mzz and netfx_extended.mzz and run command as administrator and type cd "path-to-netfx_45" than netfx_full.msi extui=1 and wait while small installation window will hide like it means completed.
   and check netfx setup verifier Net Frameworks 4.0 Client and Net Frameworks 4.0 Full
   You see that both setup of Net Frameworks 4.0 "Product verification succeeded" Yay! That is why newest frameworks haven't to bring mzz files of Net Frameworks, Haha forget sleepyhead, Bill Gates!

And Net Frameworks 4.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2 you can like my step-step from 3. you know how does it fix with Net Frameworks 4.0 and newest Net Frameworks 4.x and all net frameworks 4.0 installed successful and verified complete.

Do not forget about Net Frameworks 4.6.1 Developer Pack if it says processing net frameworks 4.6.1..
you must copy and past from Net Frameworks 4.0 but faster... to unpacking directory of Net Frameworks 4.6.1 and installer will find net frameworks 4.0 mzz files and continue to install - wait it will completed... Yay

Now you can install Visual Studio 2015 Community
I am very happy because I can fix with net Frameworks 4.0 with newest net frameworks with mzz files. yay and If you have problem with failures of installation. Sorry for hard stupid work for reinstalling with Windows.. Because Windows 7 is very sensitive.. That is why and it works fine 100 %.
Buuuut Windows 8 and 10 have sometimes bad failed installer of Net Frameworks 4.0 :( Stupid Microsoft :( I have checked netfx setup verifier with Windows 10 since it happens.. it can not fix because Windows 10 has operating system component of failed Net Frameworks 4.0 Possible has failed installer same to Windows 8 and 8.1

I hope my fixed solution helps you... If you work with Windows 7 SP 1. Thanks for taking with my good result!

And I have installed haxe 3.2.1 with HXCPP 3.3.49, Openfl 4.1.0 and Lime 3.1.0 and i type lime create helloworld and cd helloworld and lime test windows -vs14 -release than you see that is fresh. No errors yeah!