I'm using Mingw to build a C/C++ project. This project has makefiles beyond my comprehension, and relies on a custom and quite sophisticated toolchain to compile it. It's quite convenient to have GNU tools available on Windows, especially from Windows's cmd shell, but while invoking the tools (make in particular), MinGW seems to change my PATH around.
Cmd does it normally:
echo %PATH% > ... c:\Apps\msys\bin ... (from cmd)
but msys changes this address to :
echo $PATH > ... /usr/bin ...
in msys, even when I print the PATH from a makefile. As a result, make complains that it can't find commands like make, uname, echo, you name it (no pun intended).
Strangely, I managed to get this environment working ages ago without a hitch, but this is the first time I remember seeing this path problem. How can I get MinGW/msys to correctly point to its executables?
richard has a point - there were two different shells fighting over environment variables (not to mention running msys) and so each parsed its own and the system's environment variables differently.
Also make sure that variables defined in your user or system environment are properly written - Windows likes "C:\foo\bar" style paths, but Msys treats them as "/c/foo/bar".
Related
I have a Makefile with a target that prepends an environment variable to the shell call (with the usual bash syntax). This is the gist of it:
mytest:
ANSWER=42 echo Hello!
(the real deal is a programme that does something with the ENV ANSWER, but that's irrelevant here)
This works as expected in a linux/bash environment. In windows/cmd.exe environments it works to my surprise in some machines, but fails in others with this error:
> make mytest
MYVAR=42 echo Hello!
'MYVAR' is not recognized as an internal or external command,
operable program or batch file.
make: *** [Makefile:332: mytest] Error 1
Which is what I'd normally expect, since ENVVAR=<value> <command> isn't valid syntax in the windows shell. Apparently Make does some magic that I don't understand.
If I pre-export the ENV this way, it works as expected:
mytest: export ANSWER:=42
mytest:
echo Hello!
But since it works on some windows environments, I'd like to know why and maybe adapt those instead of changing a lot of Makefiles.
All of the environments are using GNU Make version 4.3.
Running on Windows is complicated because GNU make can be built in different ways there. Sometimes it is built to use Windows cmd.exe as its shell. Sometimes it's built to use an installation of sh.exe as its shell (note, GNU make never comes with a shell: the shell is a separate facility provided on the system). And sometimes it's built to use sh.exe if it can find one, else use cmd.exe.
If you're seeing different behaviors on different systems, then the way make was built is different between those systems, and/or different systems have different extra software installed so that some have sh.exe and some don't.
In a makefile, I have the following:
SHELL = $(SOME_DIRECTORY)/sh
showme:
echo $(SHELL)
This is on MS Windows. The situation is that make is in the PATH (or is being directly invoked) but an acceptable shell (i.e. sh.exe) is NOT in the PATH. Neither is it an option to globally modify the PATH variable to include a sh.exe (too much potential conflict between Cygwin, msysgit, and more). Therefore, make defaults to using the Windows cmd.exe command processor, which is hardly ideal.
It is an option to set a system-wide environment variable other than PATH however. So I had the bright idea of putting a path to the directory containing sh.exe in SOME_DIRECTORY and then using it in the SHELL variable in the makefile. But it's not working for some frustrating reason:
make
echo sh.exe
sh.exe
If I use any other variable than SHELL and echo it, then it prints the expected result. But of course that doesn't have the desired effect of changing the shell.
What am I missing here? What do I need to do to have an environment variable with a custom user-specified name (i.e. not SHELL, PATH, etc.) affect the shell used by make?
Which make are you using? GNU make (gmake) 3.82 is most common and it should work in the way you expect. As MadScientist notes, gmake behaves differently under windows wrt SHELL.
You should be able to set SHELL to the full path of an existing executable file, and gmake will use it to execute commands.
However: if SHELL is not set OR if it is set to a non-existent file, gmake will use the value of ComSpec (mind the caps) as the shell.
Is there an exe at the test path you're using? So $(SOME_DIRECTORY)/sh is an existing exe? (Note that you can omit the '.exe' and gmake will supply it for you, but the file must exist)
I have been putting together a makefile in a Windows environment for my team to use. I decided to use MinGW's version of make for Windows. I put that executable with its dependencies into a repository location that should be in everyone's PATH variable. The executable was renamed "make.exe" for simplicity.
Then I realized that I have to account for the case when someone has cygwin's bin folder in their path. Commands like echo, rmdir, and mkdir will call echo.exe, rmdir.exe, and mkdir.exe from cygwin's bin folder. This means that I need to appropriately catch this scenario and use different flags for each command.
I see three cases here:
Cygwin's bin path comes before the path where make.exe is located in the repository. When a team member executes make.exe, they will be executing cygwin's make. Unix-style commands must be used.
Cygwin's bin path comes after the path where make.exe is located in the repository. The correct make.exe will be executed, but I still have to use Unix-style commands.
Cygwin is not installed or not in the PATH. I can use all Windows commands in this case.
I am fine with treating cases 1 and 2 the same. Since MinGW's make and cygwin's make are both based on GNU Make, then I don't see this being much of an issue other than incompatibility issues between versions of GNU Make. Let's just assume that isn't a problem for now.
I have come up with the following check in my makefile.
ifneq (,$(findstring cygdrive,$(PATH))$(findstring cygwin,$(PATH))$(findstring Cygwin,$(PATH)))
#Use Unix style command variables
else
#Use Windows style command variables
endif
Finding "cygdrive" in the path variable means that we are most likely in case 1. Finding "cygwin" or "Cygwin" in the path variable most likely means that we are in case 2. Not finding either string in the path most likely means that we are in case 3.
I am not completely fond of this solution because the cygwin's folder can be renamed or the string "cygwin" or "cygdrive" can be put in the PATH variable without having cygwin installed. One team member is still having issues as he has cygwin's bin path in the PATH variable, but the above does not catch that. I am assuming that he renamed the folder to something else, but I haven't been able to check on that.
So is there a better way to figure out what syntax that I should be using?
Here is another solution that I thought up.
ifeq (a,$(shell echo "a"))
#Use Unix style command variables
else
#Use Windows style command variables
endif
This is based on the fact that 'echo "a"' in Unix will print a (without quotes) but windows will print "a" (with the quotes). If I am using the Unix style echo then I can assume that I am using all Unix commands.
I don't find this solution very elegant though, so I am not marking it as the solution for this question. I think this is better than what I originally had though.
Cygwin make v. MinGW make: Does mingw make support the jobserver, as in can you do make -j5? If not, ${.FEATURES} has jobserver for cygwin make. Maybe load is a good test too.
Cygwin before non-cygwin on path: cygpath.exe is unique to cygwin. You could just look for this in ${PATH}. Unfortunately, Windows users like using spaces in folder names, and there's no way of dealing with this in pure make. $(shell which make) will return /usr/bin/make for cygwin, though a shell invocation on every make run is very smelly.
You don't install a compiler from a repository, is not make a similar case? Just get your users to install cygwin and be done with it.
I have a book called Beginning Lua Programming which is suppose to go over the raw basics but it is sort of leaving me stranded. Here is an effort to condense 3 pages:
QUOTE:
The following environment variables are recommended for Windows:
UTIL_DIR=c:\program files\utility
LUA_DIR=c:\program files\lua\5.1
LUA_CPATH=?.dll;%LUA_DIR%\?.dll
LUA_PATH=?.lua;%LUA_DIR%\?.lua
The UTIL_DIR variable identifies the utility directory you created in the preceding section.
After this, there is a segment about setting the 'windows search path' for lua. Basically, it tells me to look up the output of 'doskey /?' and 'path' and figure it out myself. I have no idea what these do, how to use them, and what the difference between them is.
I'm at my wits end. A detailed explanation or a link to a detailed blog/article or youtube video is EXTREMELY appreciated!
There are a few ways to get Lua working on your machine. If you just want to a functional Lua environment in a hurry with minimal fuss then consider downloading one of the precompiled Lua binaries. The common ones being Lua for Windows and LuaBinaries.
Building Lua with Mingw isn't too difficult:
First get your desired Lua version here.
Extract the tar file containing Lua's source somewhere. For this example, I'll assume you extracted to c:\lua
If you have Msys already set up, you can run the make file from that environment. From the Msys shell, you can build lua with the follow commands:
cd /c/lua
make PLAT=mingw
make install
You should find lua.exe and luac.exe somewhere in there after the build completes. Lua should be ready for use at this point.
The regular cmd.exe shell can work too with some changes to the commands:
cd lua
mingw32-make PLAT=mingw
The make install assumes a *nix environment and so doesn't work under a normal windows cmd shell. In this case you can just manually copy the compiled files from .\lua\src to where you want or you can just run it directly from there if desired.
I am writing installation in a Makefile in which I need to set the PATH env. variable.
In the windows part of it, I found the following:
set: With set PATH="%PATH%;%CD%" I can change the PATH inside the running environment. There are two problems with this:
The environment is a spawned cmd.exe by make which gets its variable affected and the effect removed as soon as it closes
Even if the previous problem could be solved, still the cmd.exe that calls make would close one day and the modified PATH lost.
setx: A microsoft tool that can permanently change env. variables. According to microsoft itself, this is the only command-line option to do this. Using setx PATH "%PATH%;%CD%" -m however, turns path into the literal %PATH%;%CD% and doesn't replace the variables by their contents!
Note that I am calling make from cmd.exe not cygwin or other modified windows shells that act more like linux. What I'm saying is that, although I can use $(PATH) in my makefile (instead of %PATH%), I can't use pwd (instead of %CD%)
Also note that if in cmd itself I run:
setx PATH "%PATH%;%CD%" -m
it works perfectly. Somehow I need to make make execute this command.
Do you have any idea how to fix this, or what workaround do I have?
P.S. Just for the record, echo "%PATH%;%CD%" in the Makefile also echoes the literal "%PATH%;%CD%" rather than let cmd.exe handle it
Back in the day i Borland C++ Free Command Line tools included a version of make which played well with the dos/windows command line. Probably still floating around somewhere.
Workaround:
Create a .bat file, put the command there, and invoke it from the Makefile.
I still am interested in a direct fix in the Makefile though.