Discovery of the Visual Studio Build Tools

[orcmid]

I notice in projects/scripts/build-windows.bat that the attempt to discovery VS BuildTools uses WHERE which is great but I also see dependence on specific full-path locations of BuildTools. There are a lot of assumptions in that, none satisfied by my installation of VS 2019 Build Tools :).

In the past, I relied on the fact that there were settings that could be used to discover the the installation of VS versions and their tools, as a way of providing some automatiion for people who might download projects of mine for Windows. Here is what I get for WHERE cl.exe.

I need a more flexible procedure. I would introduce it in my nfoTools project for setting up for compilation with build tools no matter what edition is installed, and what I am building 1aylib.lib or any other project using the VC compiler . I am also a little concerned about caveates in the -? and documentation of lib.exe and link.exe about whrre these must be run under. I think that just means the necessary vcvars have been run. I have to test that.

The project I got stuck on when VS Build Tools became undiscoverable via settings can be seen in the VCbind.bat script in https://github.com/orcmid/nfoTools/tree/master/devKits/WinDev/VCbinder/devBind

If we can find a better discovery technique that a beginner script could use (say, for their first effort at building a cloned project) , I would love to incorporated that in the raylib script for batch operation too.

1. Maybe I should look for the vcvarsall.bat file directly?
2. I don't want to ask a neophyte to find and use one of the developer command prompts that are part of the Visual Studio 2019 (e.g.) folder in All Programs. I would like that to not be required.

Anyone have thoughts on this?

[raysan5]

@orcmid I think it could be difficult (and probably cumbersome) to find a solution that works for all the users. Actually, that's one of the reasons I provide a self-contained standalone package for new users.

Also note that an user that decides to follow that compilation route will probably be an advance user able to manage the required paths manually.

By the way, very impressive your nfoTools, very clear, organized and well documented.

[orcmid]

@raysan5 thanks for the compliment.

I was thinking of situations where beginners want to learn to program or want to study, maybe use, and maybe contribute to an open-source project.

I'm working through a beginner C++ for Game Development class that has been introduced on Udemy. That is where I had the good fortune to see the use of raylib and also its installer for Windows, then using VS Code on all supported platforms. Watching how beginners are crashing and burning getting the first small programs built and executed is dismaying for me.

You're right. If I presumed that standard setups applied, and there were no differences for other languages, I might be happy with the way Visual Studio Build Tools install in VS 2017, 2019, and the soon-to-be 2022. In a way, C:\raylib\ is a demonstration of such certainty. I do then have to contend with having non-standard install locations myself. (My C:\ is a 256 GB SSD and I have to be stingy with it.) I also tend to have multiple installations so I can test builds with all of them.

I am going to mull over this a bit more. I can imagine also doing a raylib setup with VSCode that uses the Microsoft Build Tools. That might be useful for tutorial and learning purposes.

[orcmid]

I have reverted to using Visual Studio Build Tools directly from cmd.exe. Doing static builds in place is easy. I have one sort-of hack for finding vcvarsall.bat.

I now need see how to accomplish the same using VS Code. Then I can look at creating and using a static raylib.lib and working that from VS Code also.

If I get anything useful I will see what can be contributed to here.

PS: I like the Using-raylib-in-VSCode wiki page and also the C++ adaptation to use objects, but now I can't find that.

[orcmid]

The current recommendation for using VS Build Tools later than VS 2015 is to make use of the "Developer Command Prompt for VS 201_x_" that is found in the Visual Studio folder under start page "All Programs." I think the "x64 Native Tools Command Prompt for VS 201_x_" is a better choice, since it is easier to find by just typing "x64" in the Windows 10 task-bar search field and clicking Enter when the first choice is the desired target. Typing command "cl" will provide confirmation. [Assumption: Internationalization of VS is one that does not interfere with this aspect.]

After that, three things need to happen.

1. Navigation to the place where compilation is intended to happen (e.g., where a project has a folder where building is intended to be conducted, usually where the source code is.
2. Optionall: Initiation of VS Code, if desired, from within the command-line session, via entry of command "code ." where the . is important. This is pretty much the only flexible way of using VS Code to provide build and terminal functions with VS Build Tools.
3. Option to the Optional: It would be handy to setup VS Code workspace support and have a configuration for building at the navigated place.

This is pretty wonky, and using Visual Studio itself (e.g., a Community edition) is certainly "simpler" in some sense. That does not get us into a nice place for using raylib though.