mkdirの使用が何度も発生し、そうでないため拒否されました
ポータブル。 私たちは、ポータブルなソリューションを受け入れています。

2018年11月12日月曜日、午後6時55分Stephan Beal < [email protected]は次のように書いています。

$（PREFIX）/ libがすでに存在するため、インストールが失敗します

[ stephan @ host ：〜/ cvs / libsass] $ m install 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と同じです、
しかし、そのチケットは不可解に閉じられています。

PS：autoconfを実行して、autotoolsで生成されたビルドを使おうとすると
configure.acをconfigureに変換すると、結果の./configureは失敗します
なぜなら：

[ stephan @ host ：〜/ cvs / libsass] $ ./configure --prefix = $ HOME
configure：エラー：スクリプト "。" / scriptでinstall-sh、install.sh、またはshtoolが見つかりません

したがって、私はツリーではなく、ツリーにチェックインされているmakefileを使用しています
autotools（別名GNU "Auto、my ass！" Tools）によって生成されたもの。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、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サポートしていることを私の左の睾丸に賭けます。

これまでのすべてで、すべてが何度も詳細に説明されてきました
クローズされた問題。 私たちは持っている懸念に対処するPRを検討します
以前に発生しました。

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 ：

autoconfによって生成されたインストールスクリプトを使用することによって対処されていない認識された制限は何ですか（ここから4つのコメントを示しています）？ このプロジェクトはautotools使用するため、ツールセットがサポートするプラットフォームへの移植性が制限されます。 したがって、 autotool'sインストールスクリプトを使用することは、提供されたmakefileを使用してプロジェクトを構築できるすべてのプラットフォームにとって最も自然で移植性の高いソリューションです。

@sgbealまだ問題を見つけることができませんが、Makefileをさらに見ると、Windowsをサポートしているようです。 Windowsでは、 mkdirはmdエイリアスであり、 -pサポートしていません。

おそらく、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」とは何か」は、正直な質問としてではなく、面白​​く意図されていました（Windowsは、前の千年紀以来、私の家庭ではありませんでした）。