mkdir을 사용하는 것이 여러 번 제기되었으며 그렇지 않기 때문에 거부되었습니다.
가지고 다닐 수 있는. 우리는 이식 가능한 솔루션에 열려 있습니다.

2018년 11월 12일 월요일 오후 6시 55분 Stephan Beal < [email protected] 작성:

$(PREFIX)/lib가 이미 존재하기 때문에 설치가 실패합니다.

[ stephan@host :~/cvs/libsass]$ m 설치 PREFIX=$HOME
mkdir /home/stephan/lib
mkdir: '/home/stephan/lib' 디렉토리를 생성할 수 없음: 파일이 존재합니다.
Makefile:263 : 대상 '/home/stephan/lib'에 대한 레시피가 실패했습니다.
make: * [/home/stephan/lib] 오류 1

수정은 간단합니다. mkdir 대신 mkdir -p를 사용하십시오.

이것은 #1992 https://github.com/sass/libsass/issues/1992 와 동일합니다.
그러나 그 티켓은 설명할 수 없을 정도로 닫혀 있습니다.

추신: autotools 생성 빌드를 사용하려고 할 때 autoconf를 실행하여
configure.ac를 구성으로 변환하면 결과 ./configure가 실패합니다.
왜냐하면:

[ stephan@host :~/cvs/libsass]$ ./configure --prefix=$HOME
구성: 오류: 스크립트 "."/script에서 install-sh, install.sh 또는 shtool을 찾을 수 없습니다.

따라서 나는 트리에 체크인 된 메이크 파일을 사용하고 있습니다.
autotools에 의해 생성된 것(GNU "Auto, my ass!" 도구라고도 함).

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/sass/libsass/issues/2727 또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAjZWC46FJREYZk3iPIdWpGiuKuKlkJ4ks5uuSlkgaJpZM4YZIEz
.

확실히 mkdir -p 는 단순히 모든 플랫폼에 설치하지 못하는 것보다 이식성이 더 좋습니까?

autotools 매뉴얼에서 가져온 휴대용 솔루션은 다음과 같습니다.

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

그 설치 스크립트는 가능한 한 이식 가능합니다. (그 파일을 제외하고 모든 autoreconf 출력을 버리고 해당 파일을 체크인하십시오.)

흥미롭게도 mkdir -p (POSIX mkdir에 의해 명시적으로 지정됨)를 사용하지만 다양한 이식성 문제도 해결합니다.

이식성: 소스 코드가 C++0x를 사용하므로 비교적 최근 플랫폼(10년 미만)에서 컴파일됩니다. 나는 그러한 모든 플랫폼이 mkdir -p 지원한다고 내 왼쪽 고환에 걸었습니다.

모든 것은 이전의 모든 문서에서 여러 번 자세히 설명되었습니다.
닫힌 문제. 우리는 문제를 해결하는 홍보를 고려할 것입니다
이전에 제기되었습니다.

2018년 11월 12일 월요일 오후 8:13 Stephan Beal < [email protected] 작성:

이식성: 소스 코드는 C++0x를 사용합니다.
비교적 최근의 플랫폼(10년 미만)에서 컴파일합니다. 나는 내기할 것이다
그러한 모든 플랫폼이 mkdir -p를 지원한다는 내 왼쪽 고환.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/sass/libsass/issues/2727#issuecomment-437808279 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAjZWDztL9XVhyClKwxTr7QVoEu2Oie3ks5uuTvQgaJpZM4YZIEz
.

@xzyfer 종료된 문제에 연결해 주시겠습니까? #1992는 그것에 대해 논의하지 않습니다.

mkdir -p 지원은 POSIX 요구 사항이기 때문에 비 이식성 주장을 이해하기 위해 토론을 읽고 싶습니다. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mkdir.html

autoconf 의해 생성된 설치 스크립트를 사용하여 해결되지 _않은_ 제한 사항은 무엇입니까? 이 프로젝트는 autotools 를 사용하므로 도구 집합이 지원하는 플랫폼으로의 이식성이 제한됩니다. 따라서 autotool's 설치 스크립트를 사용하는 것은 제공된 메이크파일을 사용하여 프로젝트를 구축할 수 있는 모든 플랫폼에 대해 가장 자연스럽고 이식 가능한 솔루션입니다.

@sgbeal 여전히 문제를 찾을 수 없지만 Makefile을 자세히 살펴보면 Windows를 지원하는 것으로 보입니다. Windows에서 mkdir 은 -p 지원하지 않는 md 의 별칭입니다.

Windows와 비 Windows에서 MKDIR 다르게 설정하는 PR을 보내시겠습니까?

자세한 내용은 아래에 있습니다. 나는 그 문제에 대해 잘 알지는 못하지만 나는 그것이 계속해서 일어나는 것을 보았다.

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 "Windows"가 무엇입니까?

빌드는 autotools를 사용하며 autotools와 함께 배포되는 install-sh를 "정말 사용해야" 합니다. _that_ 설치 프로그램이 충분히 이식 가능하지 않은 경우 autotools를 사용하는 것은 손실된 원인입니다.

@sgbeal 체크 인된 Makefile은 autotools에 의해 생성되지 않습니다. autotools를 사용할 수 없을 때 빌드하는 대체 방법입니다(예: Ruby 또는 Python용 C 확장을 위해 컴파일할 때).

이 경우 "Windows"는 gcc 및 gmake가 있지만 CMD에서 실행 중인 경우입니다(예: Cygwin Bash 또는 유사한 POSIX 환경과 반대).

그럼에도 불구하고 내 #2728 PR이 이 문제를 해결한다고 생각합니다. PR make 는 이미 존재하는 디렉토리를 더 이상 만들려고 시도하지 않아야 하기 때문입니다.

@xzyfer 감사합니다! 이것은 특히 Windows 호환성에 관한 것이라고 생각한 것 같습니다. make 가 이미 존재하는 디렉토리를 생성하려고 시도하지 못하도록 하는 #2728을 보냈습니다.

@glebm 진심으로 사과합니다. 'Windows'란 무엇인가'는 솔직한 질문이 아니라