I installed Doxygen on a Debian VM on Virtualbox, hosted by a Windows 10 pc. It runs smoothly as creates all the basic documentations, but when I enter into a latex documentation directory and try to run make it gives me the following bash report (roughly translated from italian):
rm -f *.ps *.dvi *.aux *.toc *.idx *.ind *.ilg *.log *.out *.brf *.blg *.bbl refman.pdf
pdflatex refman
make: pdflatex: command not found
Makefile:8: instruction set for target "refman.pdf" failed
make: *** [refman.pdf] Error 127
I searched for this error but I couldn't find anything about. Both the doxyfile and the latex makefile aren't modifed.
Results form generating with doxygen generated Makefile indicates that the pdflatex cannot be found.
Problem appears to be that the installation of TexLive didn't add the directory with e.g. pdflatex to the path.
I am using a makefile in windows to push some files on a Unix server (here a text file "blob.txt" in the same folder of my makefile).
My makefile script is:
setup:
pscp blob.txt username#hostname:/folder/
I start a command prompt, go in the folder where blob.txt and the makefile are present and type:
make setup
Which results in:
pscp blob.txt username#hostname:/folder/
process_begin: CreateProcess(NULL, pscp blob.txt username#hostname:/folder/, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [setup] Error 2
In a #fail ... whereas if I enter directly the command in the command prompt:
pscp blob.txt username#hostname:/folder/
It works ... I really wonder why.
The error
process_begin: CreateProcess(NULL, pscp blob.txt username#hostname:/folder/, ...) failed.
make (e=2): The system cannot find the file specified.
is almost certainly complaining that Windows cannot find pscp.
This is almost certainly because the value of %PATH% (or whatever) is different when make spawns a shell/console then when you have it open manually.
Compare the values to confirm that. Then either use the full path to pscp in the makefile recipe or ensure that the value of PATH is set correctly for make's usage.
I didn't want to remove GIT's bin folder from the PATH variable (I am using a Windows machine), as I use it quite often. So I looked for a workaround, and here it is:
Add the <git-installation-directory>/usr/bin directory to your PATH variable too. This basically adds the rest of the linux-like commands that come with the "GIT bash" to your environment. After applying this, my makefiles ran normally again. :)
If you are curious about what shell is being invoked by make, just add $(info $(SHELL)) at the beginning of your makefile. The path/name of the shell being invoked is printed to the console as soon as you run make.
I know this is an old question that has been answered, but thought I'd and my experiences for anyone still running into this. I was getting the same cryptic error Colonel Beauvel (though with the windows MOVE command, not pscp):
process_begin: CreateProcess(NULL, move /y foo\bar.c .\baz.c, ...) failed.
make (e=2): The system cannot find the file specified.
Our CI was running the same Makefile and working perfectly. Turns out CI was using mingw32-make and I was using GNU make. Uninstalling GNU make (which got installed as part of an unrelated bulk package) and aliasing mingw32-make to 'make' works perfectly.
#user3869623's solution works for me. I'd like to share some details of mine to complete the picture.
My makefile contains below target:
clean:
#echo '$(OS)'
ifeq ($(OS),Windows_NT)
del /s *.o *.d *.elf *.map *.log
endif
When I run make clean, I see this error:
Since it says something went wrong with echo, so I change my makefile target to below:
clean:
ifeq ($(OS),Windows_NT)
del /s *.o *.d *.elf *.map *.log
endif
This time, make clean gives me this error:
I am surprised to see bash here since I am working in Windows command line.
Then I checked my %PATH%, I see this entry:
C:\DevTools\Git\bin
There's a bash.exe and sh.exe in that path. So I removed this entry, and it works fine now.
BUT I STILL DON'T KNOW WHY BASH GET INTO THIS???
ADD 1
As to why the C:\DevTools\Git\bin shows up in my %PATH%, because I am using Sublime and it always asks me for the Git binaries:
In my case, I had git\bin in my %PATH% which contains bash.exe and sh.exe.
Removing %GIT_HOME%\bin from the PATH worked for me.
To build on user3869623's response.
In my case i had git\bin in my %PATH% which contains bash.exe and sh.exe.. Removing %GIT_HOME%\bin from the PATH worked for me
While this recommendation may allow make to run, it will likely cause issues for git, especially if the makefile is installing software from a git repository.
A better solution is to simply change %GIT_HOME%\bin to %GIT_HOME%\cmd
For those who tried removing the git bin folder from PATH and it didn't work for them, search your PATH variables for any paths containing bash.exe.
In my case I found a variable linking to cygwin bin folder C:\cygwin64\bin, removed it and it worked.
I had the same issue, and this thread really helped me solve it. In my case, it was a conflict between make and the sh.exe that was visible through my path, due to both git and mingw64. To fix my issue, without breaking Git, I added these lines to the top of my batch file that calls make:
set path=%path:git\bin=;%
set path=%path:mingw64\bin=;%
set path=%path:usr\bin=;%
This hides the extra sh.exe instances from make for that instance only.
I ran into this problem recently and this question was one of the top hits for my searches.
None of the other answers here helped me. The fix, for me, was to put the binary name in quotes:
setup:
"pscp" blob.txt username#hostname:/folder/
-"pscp" blob.txt username#hostname:/folder/ # Failure is OK, `-` in front
I'm on windows.
By explicitly setting my compiler to gcc (instead of cl?) it solved my problem.
CC = gcc
I hope some people more knowledgeable than me could explain why changing the compiler would impact the makefile parsing.
I finally managed to compile a program in Windows, which took a while and would have not been possible without some help from here. It all works now, except: "make clean" yields
/bin/sh: del: command not found
Makefile:44: recipe for target `clean' failed
make: *** [clean] Error 127
In the makefile, the clean command looks like
clean:
del /S *.o *~ *.out [...], eliminating all resulting .o and executables resulting from make.
mingw64 is in the path, and I tried with cygwin/bin in the path and without, both with the same result. "Make" was done with mingw32-make in msys. I also tried "mingw-32-make clean" in msys, still no luck; I am also not sure if "make clean" is supported in Cygwin at all. I run the whole thing on Windows 7, 64 bit.
How can I fix this problem?
It seems like you are mixing your platforms. del is a cmd.exe builtin, which is why it cannot be found by Bash. The analog to del is rm.
Try running make under cmd.exe
or
editing the Makefile, replacing del /S with rm -f
It is also possible to create a file called makefile.defs in you project folder and overwrite the makefile variable RM which is automatically set to "del" by eclipse. The file is included by "makefile" in the [Name of Config] folder
my File just contains:
RM := rm -rf
This works fine for me.
I have Makefile under a directory and directory has many .pm ( perl files )
I want to add makefile at this directory level which does perl file syntax checking.
Basically I want to add:
perl -c <filename>
How to get list of files automatically in that directory without hardcoding.
The following worked for me in the GNU makefile (Linux and Windows)
ALL_PM_FILES = $(wildcard *.pm)
Then run a for/foreach loop on them.
You can try the filter command:
PMFILES=$(filter %.pm, $(SRC))
Documentation for filter is hard to find. See here for an example.
This is the normal workaround:
check_pm_syntax:
for file in *.pm; do ${PERL} -c $$file; done
You run 'make check_pm_syntax' and it goes off and runs the shell loop for all the *.pm files it can find. You can simply list check_pm_syntax as a pre-requisite for your all target if you like (but it means you'll always do work when you build all). The only time this causes trouble is if there are no *.pm files in the directory.
Here's a slightly different approach:
.PHONY: check_%.pm
check_%.pm:
perl -c $*.pm
check_all: $(addprefix check_,$(wildcard *.pm))
I am generating a pdf output with pdflatex with the following command in gVim:
:!pdflatex %
This command in turns executes the following in the Command Prompt:
cmd.exe /c pdflatex /testvim.tex
Now, the problem I'm having with this is that the pdf is outputted to the system32 folder:
C:\windows\system32\testvim.pdf
How can I instruct pdflatex to generate the pdf in the folder where the tex file resides?
What about using the latex plugin for vim?
http://vim-latex.sourceforge.net/
This depends mainly on your LaTeX version. Do you use MikTeX or TeXLive ?
The pdflatex command of MikTeX has a command line option for specifying the output directory and the auxiliary directory (for .aux files).
I don't have MikTeX installed on my PC now, but you should be able to figure it out when running pdflatex --help or pdflatex /? from the command prompt.
If you are using TeXLive, you can first switch to the wanted output directory, then run pdflatex with the full path to your latex input file. This outputs everything into the current working directory, including temporary tex files.
I would suggest that you write your own runpdflatex.bat file which includes the correct call to pdflatex so you don't have to bother with it every time you want to compile your latex file.
Do you start GVim per Icon?
I do the following:
Opening Dos Box
Change to my tex-directory cd\local\tex\make
gvim foobar.tex
Executing :!pdflatex % creates the PDF document in local\tex\make not in the system32-folder