added MSVC project configuration for host-side tools

[ziggurat29]

added MSVC project configuration for host-side tools. modified code to also build with MSVC. at present, only luac.cross. later, spiffsimg.

• This PR is for the dev branch rather than for master.
• This PR is compliant with the other contributing guidelines as well (if not, please describe why).
• I have thoroughly tested my contribution.
• The code changes are reflected in the documentation at docs/en/*. ??? donde esta?

This minor enhancement provides support for building host-side tools with MSVC. This is useful for folks who are on Windows, and who already have MSVC. The host-side tools need to be native. Most of the firmware build can be done via the online web service, but to use LFC, you must have luac.cross.

The major part of this change is just conditional compilation around toolchain-specific language extensions, such as __attribute() on gcc, and functional equivalents as __declspec() for MSVC. There was a minor syntax error in luaconf.h that was masked by conditional compilation on gcc. The rest are just adapting to a few peculiarities of the libc that comes with MSVC.

The spiffsimg tool is going to be more involved than I originally thought, and I feel that having luac.cross is sufficiently meritorious in itself to warrant considering accepting this PR's content independent of that. Having a native luac.cross enables folks on Windows to enjoy the benefits of LFS -- even using the online build system since is has been extended to allow the creation of a LFS-enabled image. (I'm not even sure why one needs spiffsimg at all, but I don't mind adapting it, too. I will just do that as a separate exercise.)

Be aware that I made a couple arbitrary choices about this build configuration that may not meet your tastes:

1. I created a directory 'msvc' at the top-level of the source tree, and put all the msvc/devstudio specific stuff in there. I don't mind moving it if you prefer it to be somewhere, but I had to put it somewhere for starters.

2. I let the output files be emitted to subdirectories of that project directory; 'Win32' for x86, and 'x64' for x64 builds, and Debug and Release under those. This is in keeping with my personal practice, but if you would like the build target ('luac.cross.exe') to be emitted elsewhere, let me know. I think the Linux build squirts it out in the root?

If you don't like these choices, let me know and I'll alter them accordingly.

Lastly, I suspect that there is little need to recompile luac.cross. It might be useful to host the compiled binary for casually interested parties. I have taken pains to ensure that the built binary is statically linked such that it will run as-is on everything XP and up -- no infernal runtime dll hell. I don't know if nodemcu hosts built binaries. Regardless, it will still be useful to have the build configuration in the repo so that folks can build themselves, or for maintenance reasons.

Cheers!

[galjonsfigur]

Great PR! I wonder if it is possible to add Travis CI integration for Windows (or maybe even for macOS) because I suppose it would be really easy to add/change the code and make it incompatible with MSVC again when developing on systems with GNU toolchain.

[TerryE]

@ziggurat29. Thanks for this and I will do a static review. I did consider downloading and installing the relevant bits of MSVS to compile and test this, but I baulked at the idea of a 50Gb+ download for the relevant components of the Visual Environment. I've decided to revisit MinGW as this also produces native WinX apps that can be run at any cmd prompt but only takes less than ½Gb to install.

I wonder if it is possible to add Travis CI integration for Windows

Nope. It isn't. MS don't provide free licences for their OS which in turn means than Travis could not offer a free integration platform for Windows.

Either way without a native Windows Travis environment we need one of the committers to be capable of doing the relevant MSVS / MinGW build so that we can add the executable to our Release.

[jmd13391]

Why not just do NodeMCU firmware and LFS builds under Docker for Windows? It's quick, easy, and free. I can attest to it working great in a code development cycle for real-world production environments.

[galjonsfigur]

@TerryE

Nope. It isn't. MS don't provide free licences for their OS which in turn means than Travis could not offer a free integration platform for Windows.

I'm asking because not that long time ago Travis started supporting Windows (https://blog.travis-ci.com/2018-10-11-windows-early-release)

[TerryE]

@jmd13391 Joe, it's all about learning curve really. Using Docker is pretty painless once you've got it working. So is using Cygwin for that matter, but these are still very unfamiliar concepts to Windows users who have used a Windows-based environment for everything since they started programming. This unfamiliarity creates barriers. Having an EXE which you can download and use in a Cmd or Powershell window will be a more of a gentle step for most windows developers.

@galjonsfigur, thanks for the referenced article. I am out of date. Sorry. Reading it, the containers run in WS2016 with MSVS 2017 installed. I can see the logic of MS setting up this sort of special licence agreement with the Travis folk, especially as this comes a couple of months after their acquisition of GitHub.

Note the way that we use Travis on our cloud builder is not quite the mainstream usecase -- in particular for the case of producing Win64 images for inclusion in a package download, so we would need to be very careful that we aren't breeching the MS T&Cs here, as MS aren't very forgiving on perceived licence transgressions. Licensing aside there is also a piece of none-trivial (and possibly not yet supported) work to make our Travis build support multiple host environments. I am not sure who has the bandwidth or skills to do this.

[galjonsfigur]

@TerryE Travis can be used only to check if build won't fail on Windows - this way any licensing problems would be avoided and I would be extremely useful to have that quick way to check new changes in the tools + Travis logs build process so even without binary version of tools included in repo or release page it still would still be a neat thing.

I can see what I can do with it when I figure out how to setup everything properly - It should be just a matter of modifying .travis.yml and maybe tweaking Makefile.

[TerryE]

Hey @ziggurat29, I've also got the MinGW version working. This generates a native binary that will run happily in Cmd so long as you've also got a few MinGW DLLs installed on your machine. There's still a few wrinkles that I've got to sort (such as detecting both slash type dir separators) but at least it's a native EXE. I think that it makes sense to merge these changes into yours.

[ziggurat29]

@TerryE feel free; let me know if you need any help. I would imagine mingw is more straightforward since it's gcc based. as for dlls, I usually link static to avoid dll hell -- don't know if that's an option in the mingw. Also, windows (from the api standpoint) can tolerate either directory separator character, so it might be a non-issue. on the other hand, if the code itself is cracking paths, that's a separate story.

I have held back from doing spiffsimg until this is or is not merged, since any PR for that would be dependent on this (simply for integrating into the existing msvc configuration files).

[TerryE]

I've pulled your version and merged in my MingGW changes including a one-liner to delimit on both forward and reverse slashes. I'll rebaseline push the new version up tomorrow. I am trying to keep the MinGW make as simple as possible and running under Cmd rather than MSYS, so it has its own stripped-down mingw32-makefile.mak

[TerryE]

@ziggurat29, can you add me as a committer to your fork (its an option in settings) then I can push my latest update hostools. I've rebaselined your change against the latest dev to resolve the new conflicts, and I've also added the extra stuff to support a MinGW build of luac.cross. Thanks

[TerryE]

@ziggurat29, thanks for giving me that access. I've pushed my updates. Sorry, but this had to be a forced push because of the rebaselining against current dev. Perhaps you can just double check that the MSVS make works fine. With this PR we now have 5 different ways for WinX developers to do luac.cross compiles on Windows:

• Docker
• luac.cross make under Windows/USL
• luac.cross make using Cygwin
• luac.cross make using MinGW32
• luac.cross make under MS Visual Studio

Maybe we need to add a table somewhere in the documentation comparing these.

PS. If you do view the compare, make sure that you select dev as the comparison basis, otherwise it will default to the old version when you first raised the PR and so you will see other commits in the diff.

[ziggurat29]

@TerryE sure, no prob. I'll check it out forthwith and verify it still works and adjust if needed.
My next attempt was to be on the spiffsimg, which you stated has utility as well. Then I suppose that might be the end of the host side tools that have any use of being able to be built in msvc.