I am learning my way through the vast Haxe ecosystem. While this community forum does not seem to have many discrete categories of topics, it seems like the preferred place to get assistance with this topic. [Earlier today I posted a closely-related request for help with the community.openfl.org forum, and received excellent assistance, and I know there is wide-spread cross-pollination between the various Haxe sites/groups, but the closer I get to some understanding of the component pieces, the more it seems like I should really find a way of communicating directly with the folks responsible for HXCPP. Other than hijacking some existing topics and/or closed bug issues, opening a new topic here appears the best choice.]
So, with a suggestion from Joshua Granick, I got the clue that googling for HXCPP_COMPILE_CACHE might be useful, and indeed, that opens some links to material discussed in the nice SnowKit/HXCPP_Guide. Following that path gets me to the /haxetoolkit/haxe/lib/hxcpp/3,4,188/docs/build_xml path where there is a welter of .md files. And over at the github site git version of msvc-setup.bat is not on haxelib · Issue #666 · HaxeFoundation/hxcpp · GitHub, there is some helpful material, but I am not adept enough with any of the tools in the toolkit to be able to answer my own question, which is basically this:
Shouldn’t it be possible to share a single installation of VisualStudio 2017 on a windows workstation that dual boots between Windows 7 and windows 10?
It took me 4 hours to get through the install of the Community Edition under Windows 7 and I would not only like to avoid all that time, but all those gigabytes of space if I could just have Haxe installed/running on the Windows 10 boot pointing to the location of the necessary SDKs.
If, as it seems might be the case, the only real dependency/connections between the HaxeLib world and the MS CPP libraries is a couple of paths to where the VS stuff resides in my file system – nothing in any registry settings, nothing other than the convenience of some Shortcuts here and there – can someone provide a simple example of how to modify the .bat files with hard-coded paths that will allow haxelib and/or lime and/or openfl to successfully build for a windows target?
I have the feeling that there are quite a few other users or wannabe users of these powerful tools for development of desktop applications caught between the 32-bit world of Windows 7 and the 64-bit world of Windows 10. If the documentation and a couple of hacked .bat files would do the trick, I would be very, very appreciative.
HXCPP uses the following file when trying to pull in all of the defines and variables needed to use a Visual Studio C++ command-line environment:
For older versions of VS, defining HXCPP_MSVC (such as <setenv name="HXCPP_MSVC" value="path/to/vs" /> in a Lime/OpenFL project file, or lime config HXCPP_MSVC path/to/vs, or an ordinary environment variable) is enough to specify where to find Visual Studio. It’s possible Visual Studio might not want to run without being properly installed in the current operating system, but then again, maybe this would work. You can tell in the batch file above that Visual Studio 2017 has a different mechanism that’s a bit more complicated. You can try modifying this batch file by hand, at first, to see if you can get things to work the way you want. If it does work, please let us know, and maybe we can update the script
I hope I am understanding your question properly, and this helps!
Yep, despite my weak understanding of the architecture and terminology, you deciphered my question.
Actually, for anyone like me trying to get the current versions of haxelib, lime, openfl and hxcpp tools to behave nicely with Visual Studio 2017 on Windows 7, most of us will likely have first fallen into a hole with some sort of error message complaining about not being able to find HXCPP_VARS. Issue #51 open on the github for hxcpp correctly identifies the problem and suggests manual downloading of exactly the script file you are pointing me to.
So, I confess that I have not much attempted to write .bat files since DOS, and can see that the syntax has been much augmented, so there are things going on that are new to me, but I won’t waste your time with that. I will do some catch up reading, but maybe you can tell me whether or not you think that if there is an environment variable named HXCPP_MSVC providing a nice, absolute path to where Visual Studio lives – what evidently was the workable solution some time back with earlier versions of Visual Studio and earlier versions of HXCPP – that the invoking scripts ought to just take that path and go with it rather than trying to populate HXCPP_VARS based on whatever would be returned by “vswhere.exe”?
And, now that I see that you are intimately associated with OpenFl and Lime projects as well as being so helpful with hxcpp questions, let me stick you with this.
I have setup HXCPP_COMPILE_CACHE and observed it doing a great job of eliminating some needless recompilations. However, I just tested two OpenFL-sample programs via HaxeDevelop. The first, as expected, compiled a lot of base stuff. The second, however to my dismay, having dependencies on precisetly the same base stuff, got recompiled. That does not seem to be what the intention of the cache, via whatever indexing mechanism it uses, ought to do. If two projects both need, for example: src/lime/utils/Assets.cpp to be compiled, shouldn’t the second build project find the object already cached? If I re-test the first application, of course no unnecessary recompilation is done, but that is because FlashDevelop has long known how to keep track of whether or not any source file gets touched and does not even invoke your compiler unnecessarily.
Hmm, well I haven’t tested HXCPP_COMPILE_CACHE fully, so maybe there’s a chance that it needs to be set up a little differently. I can try to figure that out.
For the MSVC setup batch script, I think it should fall through, after not finding HXCPP_MSVC, it should try a path for Visual Studio 2017. That path (I presume) is not available on your system, but try editing that part of the script manually to point to your installation of Visual Studio. That might be enough to get it to work
As to cache behavior, I just ran another test, this time using the command line rather than the HaxeDevelop IDE, just to eliminate that variable. The results seem to be the same. openfl test BunnyMark compiles about 100-200 cpp files. openfl test PiratePig compiles about 100-120 cpp files. Where each application/project has a common dependency upon common source file – in this case, for example, let’s say openfl/ui/GameInput.cpp – even though I would think the first compilation would have cached that object, the next compilation seems not to have relied on that cached version.
As to sharing Visual Studio, since I have to reboot to go back and forth between the Windows 7 and Windows 10 test cases, I am running a little behind, but I have bashed my head against the msvc-setup.bat script for a few hours. Mostly what that reveals is how completely I fail to understand that .bat file especially in that it is being used inside other scripts/tools which seem to make it impossible for me to be able to see something like @echo I AM AT LINE 123 output.
But, I think it is also true that variables named HXCPP_VARS or HXCPP_MSVC require more than just the path to where Visual Studio is installed. The code is actually trying to set up some different compiler flags depending upon where it thinks this version of VS lives. But, the good news is that I think I know how to make a simple change from a variable definition of !installDir! to a constant and my use case making that a constant is apt to be pretty generally useful.
Obviously a dual boot disk farm is shared between the two OSes, what changes is the Letter assignments to the physical drives. The C:\ drive will be associated with one hard drive for W7 and another for W10. For all the other drives E, F, G, whatever, the correspondence can be made to be constant. That leaves the odd-drive-out needing a convenient Letter and I choose Z: So, with each boot, C: will always contain the stuff Microsoft cares about and Z: will be the odd-man-out, holding the stuff for the OS which has not been booted. That makes it easy to remember and easy to share as many paths as possible. So, since the current msvc-setup.bat script is using some program – vswhere.exe – to find out where I installed Visual Studio, I just have to stop the script from doing that because vswhere will be on C: for the OS in which VS was actually installed, but that would be Z: for the out-man-out. But, no matter, because VS2017 is actually installed on my D: drive and the mapping of the Letter D to the physical hard disk holding all that stuff remains constant.
OK, after a few more days of trying to get up to speed on all the stuff that enters into a solution to the challenge of sharing the Haxe infrastructure across Windows 7 and Windows 10, I have something that is working which I am willing to share. Since I don’t see how to attach files to this forum, I will just insert my version of the revised code here:
GOTO EC_01
2017-12-09 - SSS.
I believe that this file, msvc-setup.bat, is called whenever some haxetool is being
used to generate output for the windows target. I do not yet know how the decision is
made as to whether to call this script, or msvc64-setup.bat or msvc-winrt64-setup.bat
but I suspect that tools\hscpp\Setup.hx is the launch point.
The hack made here is to permit haxe to be installed just once to be shared by two
OS instances, namely the dual boot of Windows 7 and Windows 10. More specifically, this
hack is to allow the shared use of the whole Visual Studio 2017 kit-and-kaboodle installed
only once since that process consumes several hours of install-de-install time over my
ADSL network in addition to consuming tens-of-gigabytes of file space.
The hack depends upon dual boot involving three different Volumes which may be hard
disk [HD] drives or solid state [SSD]. Let's just call them V1, V2 and V3. V1 will have
installed Windows 7 and V3 will have installed Windows 10. The challenge arises because
Windows and its scripting will refer to this Volumes via Letters and the Letter C: will
be mapped to V1 in the case of a Windows 7 boot, but it will be mapped to V3 when booting
Windows 10. We have no way of changing tht default behavior. What we do have is the ability
to assign Letters to Volumes for the other two Volumes and we use this convention in order
to introduce as much common path location syntax as possible:
OS: Letter: Volume:
W7 C: V1
D: V2
Z: V3
W10 C: V3
D: V2
Z: V1
I hope this makes it clear that what we have done is cause the Letter D: to always map
to the same Volume, so that is where we want to install as much software as we can in order
to have it share nicely between scripts running under either OS boot.
So, we install the haxe ecosystem on D: and we install the VS2017 kludge on D:. That should
explain why the short-cut in this script works. It works because we know where the VS2017
kludge lives and we know that only the OS boot for the OS under which VS2017 was installed
could be relied on to have the necessary stuff installed at %ProgramFiles(X86)%.
:EC_01
setlocal enabledelayedexpansion
@set InstallDir=D:\SW\VS2017
@if exist "!InstallDir!\Common7\Tools\VsDevCmd.bat" (
@call "!InstallDir!\Common7\Tools\VsDevCmd.bat" -arch=x86 -app_platform=Desktop -no_logo
@echo HXCPP_VARS
@set
) else (
@echo Warning: Could not find Visual Studio 2017 VsDevCmd.
)
