Calling batch files with make and making changes persistent - windows

I'm programming with Visual C++ Express on the command line using makefiles (GNU Make).
For this to work, I have to call the Visual Studio batch file vsvars32.bat to set up the environment. This has to be done everytime I open a new cmd.exe, before using make.
When I try to call the batch file from my makefile, it obviously executes the batch file as
an own process, because the environment is the same afterwards.
So my question: is there a way to execute scripts in cmd.exe like the built-in source command of the Linux/Unix bash? Apart from installing bash on Windows, of course.
Edit after posting my own answer:
The above question is not quite right, it should be like this:
Is it possible to call an environment-changing batch file from within a makefile, so that the changed environment persists for the other programs called in the makefile?
The answer to the original question is yes: you can use the built-in call command of cmd.exe. But since call is a built-in command and not a real program, it doesn't work in a makefile, only if you call a batch file from another batch file.

Answer compiled from the previous answers:
I made a batch file called make.bat which contains the following:
call "%VS90COMNTOOLS%vsvars32.bat"
call make.exe %*
This does the job.
But calling an environment-changing batch file from within a makefile, so that the changed environment persists for the other programs called in the makefile, seems to be impossible.
Edit: After overflowing my PATH variable by repeatedly calling vsvars32.bat, I made the following changes:
if not "%VISUALCVARS%" == "TRUE" (
set VISUALCVARS=TRUE
call "%VS90COMNTOOLS%vsvars32.bat"
)
call make.exe %*

use 'Call':
#echo off
pushd.
call "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars3235.bat"
msbuild LinqSupportClassesSDKBuild.csproj /t:rebuild /p:Configuration=Release /nologo /v:q /clp:ErrorsOnly;
popd
this is the cmd file we use to build our linq provider.

At least in my install of Visual Studio (albeit somewhat ancient VS .NET 2003), one of the links in the VS start menu group is to open a cmd.exe instance with the environment already setup. You might find these helpful:
How to Add Visual Studio Command Prompt (VSCP) to your IDE as a tool?
Running the command prompt from visual studio tools menu
Shortcut: Launch Visual Studio Command Prompt from Visual Studio
They are more geared toward launching the command prompt from the IDE, but they do include information on launching it with the appropriate environment as well which you may find helpful for your purposes.

How do you launch your console? If you are just launching 'cmd' then instead, create a shortcut that executes (%comspec% resolves to c:\windows\cmd.exe or whatever is relevent on your system)
%comspec% /k ""C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat"" x86
Obviously, change the path to point to the proper installation folder.
More generally, as the above poster pointed out, if a .cmd file needs to process another .cmd file rather than launch it as a seperate process, use the 'call' batch command.

Wrap GNU make in a script (mmake.bat). Put the script in the path somewhere.
The script itself should run the vsvars32.bat and then make, like this
vsvars32.bat
make %*
As far as I remember, invoking a script from another script like this is done within the same shell (similar to Bash "." command).

I have found three solutions to this problem:
1) If the environment variables being set by the batch file are static (that is, they are always the same values), set those values for your entire user profile. Right-click on My Computer, click Properties-->Advanced-->Environment Variables. Add the variables from the batch file to the User Variables or System Variables section (User variables are only visible by you, System variables are visible by all users of that computer).
2) Write a wrapper batch file that calls the environment setup script then calls the Makefile.
3) Instead of using the SET command to set environment variables in the batch file, use the SETX command (requires the Windows Resource Kit). SETX is similar to SET, except it makes its changes to the master environment in the registry and will take effect in all command prompts launched in the future (but not the current one).

Related

Running VS 2017 Build Tools in Windows PowerShell

I dislike IDEs, so I installed the VS 2017 Build Tools so I can work via command-line.
The install went fine, and everything works out of Windows CMD, however, PowerShell is much better, and I prefer to use PS. The issue here is that according to MSDN:
The Visual C++ command-line tools use the PATH, TMP, INCLUDE, LIB, and LIBPATH environment variables, and may also use tool-specific environment variables. Because the values of these environment variables are specific to your installation, and can be changed by product updates or upgrades, we recommend that you use vcvarsall.bat or a Developer Command Prompt shortcut instead of setting them yourself. For information about the specific environment variables used by the compiler and linker, see CL Environment Variables and LINK Environment Variables.
I shouldn't set the Environment Variables myself, and that's fine with me, the only issue is that when I run the vcvarsall.bat in PS, no environment variables change. I am new to PS, so I'm guessing that .bat files can't alter session environment variables. If that's the case, then I can't work out of PS. As a side note, the CL and LINK variables never show up, I'll explain below.
I figured I should find out what the variables are. I echoed all my variables to a text file before and after running the batch file, and wrote a short Java program to find anything new, or modified. These are them. As you can see the CL and LINK variables are not present.
How do I solve this issue? I was thinking of writing my own batch file, but if the first one didn't work, why would mine? I didn't see anything on the attached MSDN page, or any links there about how to make this work for PowerShell.
Write a batch file that 1) invokes vcvarsall.bat, and 2) invokes PowerShell, like so (this one is specific to VS 2015):
#CALL "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" %*
#start powershell
%* allows us to pass the same arguments to this file as you would to vcvarsall.bat.
PowerShell will then run with the environment block prepared for it. The other way around doesn't work because PowerShell doesn't execute batch files itself -- it relies on cmd to do that, and as a child process, that has its own environment block that doesn't reflect on its parent.
<#
.SYNOPSIS
Invokes the specified batch file and retains any environment variable changes it makes.
.DESCRIPTION
Invoke the specified batch file (and parameters), but also propagate any
environment variable changes back to the PowerShell environment that
called it.
.PARAMETER Path
Path to a .bat or .cmd file.
.PARAMETER Parameters
Parameters to pass to the batch file.
.EXAMPLE
C:\PS> Invoke-BatchFile "$env:ProgramFiles\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"
Invokes the vcvarsall.bat file. All environment variable changes it makes will be
propagated to the current PowerShell session.
.NOTES
Author: Lee Holmes
#>
function Invoke-BatchFile
{
param([string]$Path, [string]$Parameters)
$tempFile = [IO.Path]::GetTempFileName()
## Store the output of cmd.exe. We also ask cmd.exe to output
## the environment table after the batch file completes
cmd.exe /c " `"$Path`" $Parameters && set " > $tempFile
## Go through the environment variables in the temp file.
## For each of them, set the variable in our local environment.
Get-Content $tempFile | Foreach-Object {
if ($_ -match "^(.*?)=(.*)$") {
Set-Content "env:\$($matches[1])" $matches[2]
}
else {
$_
}
}
Remove-Item $tempFile
}
$VcVars = 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Auxiliary\Build\vcvarsall.bat'
Invoke-BatchFile $VcVars x64
cl hello_world.cpp

Configuring cl CMD compiling Windows

I have already read on MSDN.com that to enable command line compilation through the cl command you have to run the vcvarsall.bat file. I have run this file in CMD and compiled code using the cl command. The issue is that after I leave the CMD and reopen it, I no longer have the ability to use cl and have to rerun vcvarsall.bat every time I reopen CMD. Is there any way to avoid having to do this? Thanks.
Just create a shortcut on your desktop that calls
cmd /k "%VS140COMNTOOLS%\vsvars32.bat"
Adapt the environment variable and batch file name to fit your installed VS version number. In the example above, this will work with Visual Studio 2015.

How to run application from command prompt with arguments?

I have an application named DriveMaster which I want to run from command line with different arguments. The application is residing in:
"C:\Program Files (x86)\ULINK DM2012 PRO NET\v970\DriveMaster.exe\"
Now in Windows - Run, if I open command prompt and want to give a command like:
DriveMaster /s:Scriptname.srt
This should be able to launch DriveMaster with that particular script.
How can I do this? What should I need to add in the Environment variables so that I can run the application from command prompt?
In Windows 7:
In the menu Start click Computer
In the context menu, select System Properties
Select Advanced System Settings -> tab Advanced
Select Environment Variables Menu System Variables to find the PATH variable and click it.
In the editing window, change the PATH, adding value: ; C:\Program Files (x86)\ULINK DM2012 PRO NET\v970
Open Run and type: DriveMaster /s:Scriptname.srt
That's all.
When you're in the command prompt the working directory is given in the prompt:
C:\Users>
Here, I'm in the folder C:\Users. If I want to run a program or a script in the folder I'm currently in, I can use its name alone (e.g. DriveMaster). If the program is outside my working directory, I can't call it like that because there could be many DriveMasters in different folders throughout my computer. I can either change my directory to be the one that has this program, or I can specify where in the filesystem it's located.
Changing the directory and running:
C:\Users> cd "C:\Program Files (x86)\ULINK DM2012 PRO NET\v970\"
C:\Program Files (x86)\ULINK DM2012 PRO NET\v970> DriveMaster
Specifying the full path:
"C:\Program Files (x86)\ULINK DM2012 PRO NET\v970\DriveMaster"
(I need to use quotes here because the folder names have spaces and my command prompt may not know if it's part of the folder name or the beginning of another command or argument.)
On the same line I call the program, I can choose a number of arguments (also called options, switches, flags) to change the way to program behaves. If my program accepts another file and wants it in the form /s: and-then-the-filename, that file also needs to be in my working directory. If it lives somewhere else, I can use the full specification, like I've done above.
Environment variables are a little more complicated of a topic, but there is one we might be interested in here. The Path environment variable is a list of folders that the command prompt will look in when you try to use names of files that aren't in your working directory. If I know I'm going to be using this program frequently and like where it is, I can add its folder to my Path so that I can access it with just DriveMaster in the future:
set PATH=%PATH%;C:\Program Files (x86)\ULINK DM2012 PRO NET\v970
(If I mistype that command, though, I could break other things in a way that would be hard to fix.)
In a file name drivemaster.bat whch would be located at some point in the path,
#echo off
setlocal
"C:\Program Files (x86)\ULINK DM2012 PRO NET\v970\DriveMaster.exe" /s:Scriptname.srt
where Scriptname.srt would need to be quoted and supplied with a full pathname if it's not in the current directory.
Oh you want to type DriveMaster /s:Scriptname.srt
Then use
"C:\Program Files (x86)\ULINK DM2012 PRO NET\v970\DriveMaster.exe" %1
in that script in place of the original "c:..." line.
edit : removed stray terminal backslash from ...exe

Porting shell functions to cmd.exe: Is it possible to automatically source scripts on startup?

I'm porting a Linux tool-set that makes frequent use of shell functions to provide certain functionality. These functions are automatically sourced when you start a new shell and include things like changing the working directory, which is nigh impossible with stand-alone programs because child processes can't change their parent's environment.
For example, there is a function cdbm which changes the working directory to one that was previously bookmarked. Now I want to do the same on Windows, but I'm stuck with cmd.exe. As far as I understand the scripts could be ported to jscript, vbscript or plain batch, which shouldn't be a problem. But how do I make sure they automatically get sourced on startup and live in the shell's environment?
According to help cmd:
If /D was NOT specified on the command line, then when CMD.EXE starts, it
looks for the following REG_SZ/REG_EXPAND_SZ registry variables, and if
either or both are present, they are executed first.
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun
and/or
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun
As a test, in regedit I created a new key in the HLM branch shown above called "AutoRun" with the string value "echo Hi". When I started a new instance of cmd I got:
Microsoft Windows [Version 6.0.6000]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
Hi
C:\Users\Username>
You could put in the name of a script to run instead (I would put in a fully specified path to the script or one with a environment variable in it like "%HOMEPATH%\scripts\scriptname" (including the quotes in case there are spaces in the name).
Edit:
The registry key has some side effects. One example is help. If I have the echo command above, for example, in the AutoRun when I type help vol I get a "Hi" right above the help text. Doing vol /?, though doesn't do that.
You can set either of the following registry keys to a batch file or other executable to run that program when CMD is started:
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun
A batch file should be able to change the current directory of the executing CMD process with the CD command, as it doesn't run as a subprocess. You can disable the autorun behaviour by supplying /D as a switch to CMD.
See CMD /? for more details.
Since cmd doesn't allow you to define functions in global scope, I'm a little at a loss to understand what exactly you're trying to achieve by auto-sourcing a script at startup. I tend to include a batch file directory in my path where you can put batch files I regularly need.
Look at cygwin.

How to use system environment variables in VS 2008 Post-Build events?

How do I use system environment variables in my project post-build events without having to write and execute an external batch file? I thought that it would be as easy as creating a new environment variable named LHDLLDEPLOY and writing the following in my post-build event textbox:
copy $(TargetPath) %LHDLLDEPLOY%\$(TargetFileName) /Y
copy $(TargetName).pdb %LHDLLDEPLOY%\$(TargetName).pdb /Y
...but alas, no. The build output shows that it wrote the files to the "%LHDLLDEPLOY%" folder (as "1 file(s) copied" twice), but the files are not in the equated path and there is not a new folder called "LHDLLDEPLOY"
Where did they actually go, and how do I do this correctly?
(UPDATE: Xavier nailed it. Also, his variable format of $(LHDLLDEPLOY) worked after I rebooted the machine to refresh the environment variables.)
(UPDATE 2: Turns out that I did not have to reboot my machine. I just needed to make sure that I a) closed the Environment Variables list window, and b) closed/relaunched Visual Studio.)
Did you try $(LHDLLDEPLOY) instead of %LHDLLDEPLOY%?

Resources