Makefile falha quando CygWin no caminho

0

Estou tentando descobrir por que um comando simples do Windows no makefile falha somente quando a pasta binária CygWin é incluída na variável PATH.

Para tirar a maioria das variáveis da equação, estou usando o makefile barebone abaixo:

clean:
    del /F /Q file.txt

Estou executando o GNU make 3.81 de um diretório que contém apenas make.exe e makefile .

C:\temp\test>dir /b
make.exe
makefile

C:\temp\test>make -v
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for Windows32

Quando o PATH inclui a pasta binária do Cygwin, recebo um erro ProcessCreate ().

C:\temp\test>path=c:\tools\cygwin\bin

C:\temp\test>make clean
del /F /Q file.txt
process_begin: CreateProcess(NULL, del /F /Q file.txt, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [clean] Error 2

Funciona como esperado, caso contrário.

C:\temp\test>set path=

C:\temp\test>make clean
del /F /Q file.txt
Could Not Find C:\temp\test\file.txt

Isso não faz sentido para mim.
Alguma ideia do que poderia estar acontecendo aqui?

    
por DavidPostill 09.01.2017 / 21:12

1 resposta

1

Fiz alguns progressos depois de mais experiências e leituras. Eu acho que entendo a lógica agora.

Parece que todos os comandos de receita no makefile são exclusivamente comandos de shell uma vez sh.exe in no PATH . Eles não podem ser comandos do Windows.

Após remover sh.exe de cygwin/bin , o makefile original funcionou como eu esperava. 'cmd' também pode ser explicitamente especificado em vez do padrão 'sh' no makefile da seguinte forma:

clean:
    cmd /c 'del /F /Q file.txt'

Se isso estiver correto, isso é um pouco decepcionante. Por ter cygwin/bin no 'PATH', eu estava assumindo que qualquer tipo de comando poderia ser usado no makefile, assim como nos comandos do windows ou no arquivo de lote.

O que ainda não faz muito sentido para mim é que os comandos do Windows funcionem quando o sh.exe não está ao alcance. Ainda falta parte da lógica.

(desculpe por postar no site errado, pensei que eu estava no stackoverflow. Se o moderador pode mover ou excluir este post, por favor, faça.

    
por 10.01.2017 / 00:53