O uso de mkdir surgiu várias vezes e foi rejeitado porque não é
portátil. Estamos abertos a soluções portáteis.

Na segunda-feira, 12 de novembro de 2018, 18:55, Stephan Beal < [email protected] escreveu:

a instalação falha porque $ (PREFIX) / lib já existe

[ stephan @ host : ~ / cvs / libsass] $ m install PREFIX = $ HOME
mkdir / home / stephan / lib
mkdir: não é possível criar o diretório '/ home / stephan / lib': O arquivo existe
Makefile: 263 : a receita para o destino '/ home / stephan / lib' falhou
make: * [/ home / stephan / lib] Erro 1

A correção é trivial: use mkdir -p em vez de mkdir.

Este é o mesmo que # 1992 https://github.com/sass/libsass/issues/1992 ,
mas esse ingresso está inexplicavelmente fechado.

PS: ao tentar usar a compilação gerada por autotools, executando autoconf
para converter configure.ac em configure, o ./configure resultante falha
Porque:

[ stephan @ host : ~ / cvs / libsass] $ ./configure --prefix = $ HOME
configure: erro: não é possível encontrar install-sh, install.sh ou shtool no script "." / script

Portanto, estou usando o makefile que é registrado na árvore, ao invés de
aquele gerado por autotools (também conhecido como GNU "Auto, my ass!" Tools).

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/sass/libsass/issues/2727 ou silencie o tópico
https://github.com/notifications/unsubscribe-auth/AAjZWC46FJREYZk3iPIdWpGiuKuKlkJ4ks5uuSlkgaJpZM4YZIEz
.

Certamente mkdir -p é mais portátil do que simplesmente não instalar em qualquer plataforma?

Aqui está uma solução portátil, retirada do manual do autotools:

Na verificação da libsass:

autoreconf --install
...
configure.ac:15: installing 'script/install-sh'
...
[stephan<strong i="7">@host</strong>:~/cvs/libsass]$ l ./script/install-sh
-rwxr-xr-x 1 stephan stephan 15155 Nov 12 10:07 ./script/install-sh

Esse script de instalação é o mais portátil possível. (Simplesmente jogue fora toda a saída de autoreconf além desse arquivo e faça o check-in desse arquivo.)

Curiosamente, ele usa mkdir -p (que aparentemente é especificado por POSIX mkdir), mas também resolve vários problemas de portabilidade.

A propósito da portabilidade: o código-fonte usa C ++ 0x, o que significa que está compilando em uma plataforma relativamente recente (menos de 10 anos). Aposto meu testículo esquerdo que todas essas plataformas suportam mkdir -p .

Tudo foi explicado em detalhes várias vezes em todas as anteriores
questões fechadas. Vamos considerar um pr que aborda as preocupações que têm
anteriormente criado.

Na segunda-feira, 12 de novembro de 2018, 20h13, Stephan Beal < [email protected] escreveu:

A propósito da portabilidade: o código-fonte usa C ++ 0x, o que significa que é
compilando em uma plataforma relativamente recente (menos de 10 anos). aposto
meu testículo esquerdo que todas essas plataformas suportam mkdir -p.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/sass/libsass/issues/2727#issuecomment-437808279 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAjZWDztL9XVhyClKwxTr7QVoEu2Oie3ks5uuTvQgaJpZM4YZIEz
.

@xzyfer Você pode

Gostaria de ler a discussão para entender as alegações de não portabilidade, porque o suporte mkdir -p é um requisito POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mkdir.html

Que limitação percebida _não_ é abordada usando o script de instalação gerado por autoconf (demonstrado 4 comentários a partir daqui)? Este projeto usa autotools e, portanto, é limitado em portabilidade para plataformas que o conjunto de ferramentas suporta. Usar o script de instalação autotool's é, portanto, a solução mais natural e portátil para todas as plataformas em que o projeto pode ser construído usando os makefiles fornecidos.

@sgbeal Embora eu ainda não consiga encontrar o problema, olhando mais adiante no Makefile, ele parece oferecer suporte ao Windows. No Windows, mkdir é um apelido para md , que não oferece suporte a -p .

Talvez enviar um PR que defina MKDIR diferente no Windows e não no Windows?

Muitos detalhes abaixo. Não estou bem familiarizado com o problema, mas tenho visto isso surgir repetidamente.

https://github.com/sass/libsass/pull/795#discussion_r22396485
https://github.com/sass/libsass/pull/2486
https://github.com/sass/libsass/pull/2109
https://github.com/sass/libsass/issues/1433
https://github.com/sass/libsass/pull/1365#issuecomment -123325642

@glebm o que é "Windows"?

A compilação usa autotools e "realmente deveria" usar o install-sh, que é distribuído com autotools. Se _tesse_ instalador não for portátil o suficiente, usar as ferramentas automáticas é uma causa perdida.

@sgbeal O Makefile verificado não é gerado por autotools. É uma forma alternativa de construir quando as ferramentas automáticas podem não estar disponíveis (por exemplo, ao compilar isso para uma extensão C para Ruby ou Python).

"Windows", neste caso, é quando você tem, por exemplo, gcc e gmake, mas está executando-o a partir do CMD (ao contrário de, por exemplo, Cygwin Bash ou um ambiente POSIX semelhante).

Independentemente disso, acho que meu # 2728 PR resolve esse problema, já que PR make não deve mais tentar criar diretórios que já existam.

@xzyfer Obrigado! Parece que acertei que se trata especificamente da compatibilidade do Windows. Enviado # 2728 que deve simplesmente impedir make de tentar criar diretórios que já existem.

@glebm minhas sinceras desculpas: 'o que é um "Windows"' foi pensado de forma jocosa (o Windows não é uma coisa em minha casa desde o último milênio), não como uma pergunta honesta, e isso não tem lugar neste fórum.