Windows 10 Makefile source The system cannot find the file specified - makefile

I have a very simple makefile that I'm trying to execute in git-bash on a Windows 10 machine.
The contents of the makefile are:
start:
source env.sh
Where env.sh is a local file that exists.
If I execute the command make start I receive the following error:
process_begin: CreateProcess(NULL, source env.sh, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [Makefile:2: start] Error 2
However, if I execute source env.sh at the command prompt all is well and I receive no error at all.
I've seen other posts like this Windows 10 Makefile error make (e=2): The system cannot find the file specified which report a similar error, but the linked question is to do with docker being on the path which I don't think applies here.
Is there any reason why the makefile errors but typing the command does not?

On Windows by default, GNU make always runs the Windows cmd.exe shell. The recipe that you're running here is a bash command.
You say it works at the command prompt but that's because the command prompt you're using is from Git bash; if you opened a Windows terminal and typed that command it wouldn't work.
If you want to use a different shell than the default you need to set the SHELL make variable in your makefile:
SHELL := <path to git bash>

Related

Make cannot be called from script without sourcing the script

I want to call the make command from a bash script in a MinGW bash shell. However the script seems to know "make" only when I call the script using source:
build.sh:
#!/bin/bash
make all
Calling
source build.sh
from the terminal works: The target all is built.
Calling only
build.sh
from the terminal results in
./build.sh: line 2: make: command not found
Why do I have to source the script to have a working make command?

Makefile Windows: .. is not recognized as an internal or external command when changing directory

I'm seeing a strange issue when trying to change directory from inside a Makefile in Windows. My pseudo-code is as follows:-
all:
cd ../ProjectDir && ../AutoExc InputFile.h
Where AutoExc is an executable that I have in the parent directory. When I run 'make' from the command line, I see the following output:-
cd ../ProjectDir && ../AutoExc InputFile.h
'..' is not recognized as an internal or external command.
The strange thing is that running this exact Makefile in Linux works. I have also tried running the above command from the command line in Windows and it worked, so there isn't an issue with 'cd' for example.
Any idea why this is happening and what can I do to get it to work? If there's an issue with the version of Make, is there another more reliable mechanism to change directory and run an executable on Windows?
I am using Make version 3.81 on Windows 7 (latest) and Make version 4.1 on Linux 4.15.0-20-generic #21-Ubuntu. I have 'cd' installed as part of 'Git for Windows', the git version is 2.16.1.windows.4.
Your command contains shell characters and is passed down to cmd.exe:
>cd ../Public && ../test
'..' is not recognized as an internal or external command,
operable program or batch file.
>cd ../Public && ..\test
'..\test' is not recognized as an internal or external command,
operable program or batch file.
i.e. cmd.exe interprets ../test as command .. with option /test.
I guess one solution would to apply a macro to command names with paths, e.g. (note: untested, just typed from my head):
if (...I'm running under Windows...)
convert_path = $(subst /,\\,$(1))
else
convert_path = $(1)
endif
all:
cd ../ProjectDir && $(call convert_path,../AutoExc) InputFile.h
or, if possible, use the suggestion from the comments SHELL := /bin/sh, or whatever the correct path is to a UNIX compatible shell in your Windows environment. "Git for Windows" is AFAIR based on MinGW, so you should have bash available.

gmake using sh.exe causes build errors

I have a makefile that works on a Windows system when sh.exe is not on path. But when sh.exe is on Windows path, it stops with an error. Apparently, sh.exe can not handle paths with mixed / and \ such as this one:
cc $CFLAGS) C:\a\b/c/d/myfile.c
it generates the following error
Fatal error: could not open source file "c:ab/c/d/myfile.c"
As I am not able to change the makefile (it is auto generated by some application), how can I force gmake not to use sh.exe or force sh.exe to accept such files?
Try gmake SHELL="cmd". See the GNU make docs for more information. In particular, note this tidbit:
Note that this extended search for the shell is limited to the cases
where SHELL is set from the Makefile; if it is set in the environment
or command line, you are expected to set it to the full pathname of
the shell, exactly as things are on Unix.

Running a bash shell script on Windows from within in Notepad++ using NppExec (and Cygwin)

I'm trying to reconstruct how to execute a bash shell .sh file on my Windows machine from within Notepad++ using NPPExec. (I've done this successfully before, but my HDD crashed and I don't recall how I did it previously.)
When it was working before, I would run the NPPExec script that called a .sh file, and it showed me the console output of the .sh file processing in Notepad++ as if it were processing in cygwin.
This is the example .sh file that I'm trying to get to work:
message="Testing"
echo $message
This file is located in the root of C:.
Failed Attempts:
None of the following three methods work:
Execute: C:\nppexec.sh
Response:
CreateProcess() failed with error code 193:
%1 is not a valid Win32 application.
Execute: npp_exec C:\nppexec.sh
Response:
message="Testing"
CreateProcess() failed with error code 2:
The system cannot find the file specified.
$message
Adding #! /bin/bash to the .sh file as the first line just causes an additional error when npp_exec is run:
NPP_EXEC: C:\nppexec.sh
#! /bin/bash
CreateProcess() failed with error code 2:
The system cannot find the file specified.
The solution was to call bash directly:
C:\cygwin\bin\bash --login -c "command.sh"
I have the same error while trying to execute a batch file on windows.
I resolved the problem by executing at first command cmd in console of notepad++, then E:\test.bat
I also have a mksnt installed on my window pc.
by starting at first the bash in console of notepad++, the test shell work well now
bash
C:\nppexec.sh
With a single keystroke I wanted to execute the shell script of the active Tab using Cygwin within notepad.
After few hours looking online and experimenting, I finally came up with
install NppExec plugin
Hit F6
paste the following code:
//save the file
NPP_SAVE
//redirect console output to $(OUTPUT) & silent mode
npe_console v+ --
//convert winpath to cygpath
D:\cygwin64\bin\bash -lc "cygpath \"$(FULL_CURRENT_PATH)\"
//execute the file
D:\cygwin64\bin\bash -lc "$(OUTPUT)"
Hope that save some time to some people
Use this Run command
C:\cygwin64\bin\bash.exe -l -c "cd \"$0\" ; echo $#; \"./$1\"; exec bash;" "$(CURRENT_DIRECTORY)" "$(FILE_NAME)"
You can save this command for later use from Run dialog box.
For git bash, change the path like this:
C:\Progra~1\Git\bin\bash -l -c "cd \"$0\" ; echo $#; \"./$1\"; exec bash;" "$(CURRENT_DIRECTORY)" "$(FILE_NAME)"

Why does make tell me "Command not found"?

I have the following simple makefile:
all:
fat_imgen.exe
Where fat_imgen.exe is an executable in the same directory as the makefile. When I try and run this however this happens:
>make
fat_imgen.exe
make: fat_imgen.exe: Command not found
make: *** [all] Error 127
If I run fat_imgen from that same command prompt then it starts as expected - why can't make find fat_imgen.exe?
This is all running under Mingw / Windows.
When using a simple commend like the name of an executable, GNU make will start the executable directly. If the directory where the executable is found is not in the PATH/path, make will fail.
If you put the directory in the path, your makefile should work normally.
Also, as suggested in a comment by #AlexFarber, by adding './' GNU make will assume a more complex command (since not all shells are created equal), and hand the command over to the configured shell. That will work, since the shell is created in the directory where the command is then found.

Resources