Die Verwendung von mkdir ist mehrmals aufgetreten und wurde abgelehnt, weil dies nicht der Fall ist
tragbar. Wir sind offen für Lösungen, die tragbar sind.

Am Mo., 12. Nov. 2018, 18:55 Uhr schrieb Stephan Beal < [email protected] :

Installation schlägt fehl, weil $(PREFIX)/lib bereits existiert

[ stephan@host :~/cvs/libsass]$ m install PREFIX=$HOME
mkdir /home/stephan/lib
mkdir: Verzeichnis '/home/stephan/lib' kann nicht erstellt werden: Datei existiert
Makefile:263 : Rezept für das Ziel '/home/stephan/lib' fehlgeschlagen
make: * [/home/stephan/lib] Fehler 1

Die Lösung ist trivial: Verwenden Sie mkdir -p anstelle von mkdir.

Dies ist das gleiche wie #1992 https://github.com/sass/libsass/issues/1992 ,
aber dieses Ticket ist unerklärlicherweise geschlossen.

PS: Wenn Sie versuchen, den von Autotools generierten Build zu verwenden, indem Sie autoconf ausführen
Um configure.ac in configure zu konvertieren, schlägt die resultierende ./configure fehl
da:

[ stephan@host :~/cvs/libsass]$ ./configure --prefix=$HOME
configure: error: install-sh, install.sh oder shtool kann im Skript "."/script . nicht gefunden werden

Daher verwende ich das Makefile, das in den Baum eingecheckt ist, anstatt
die von Autotools generierte (auch bekannt als GNU "Auto, my ass!" Tools).

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/sass/libsass/issues/2727 oder den Thread stummschalten
https://github.com/notifications/unsubscribe-auth/AAjZWC46FJREYZk3iPIdWpGiuKuKlkJ4ks5uuSlkgaJpZM4YZIEz
.

Sicherlich ist mkdir -p portabel, als einfach die Installation auf keiner Plattform zu versäumen?

Hier ist eine tragbare Lösung aus dem Autotools-Handbuch:

Von der libsass-Kasse:

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

Dieses Installationsskript ist so portabel wie es nur geht. (Werfen Sie einfach die gesamte Ausgabe von autoreconf außer dieser Datei weg und checken Sie diese Datei dann ein.)

Lustigerweise verwendet es mkdir -p (was anscheinend von POSIX mkdir spezifiziert wird), aber es umgeht auch verschiedene Portabilitätsprobleme.

Apropos Portabilität: Der Quellcode verwendet C++0x, was bedeutet, dass er auf einer relativ neuen Plattform (weniger als 10 Jahre alt) kompiliert wird. Ich würde meinen linken Hoden wetten, dass alle diese Plattformen mkdir -p .

Alles wurde in allen vorherigen mehrfach ausführlich erklärt
geschlossene Themen. Wir werden einen PR in Betracht ziehen, der die Bedenken anspricht, die haben
zuvor angehoben worden.

Am Mo., 12. Nov. 2018, 20:13 Uhr schrieb Stephan Beal < [email protected] :

Apropos Portabilität: Der Quellcode verwendet C++0x, was bedeutet, dass es
Kompilieren auf einer relativ neuen Plattform (weniger als 10 Jahre alt). ich würde wetten
mein linker Hoden, dass alle diese Plattformen mkdir -p unterstützen.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/sass/libsass/issues/2727#issuecomment-437808279 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAjZWDztL9XVhyClKwxTr7QVoEu2Oie3ks5uuTvQgaJpZM4YZIEz
.

@xzyfer Kannst du bitte auf das geschlossene Problem verlinken? #1992 diskutiert es nicht.

Ich würde die Diskussion gerne lesen, um die Behauptungen der Nicht-Portabilität zu verstehen, da mkdir -p Unterstützung eine POSIX-Anforderung ist: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mkdir.html

Welche wahrgenommene Einschränkung wird _nicht_ behoben, indem das von autoconf generierte Installationsskript verwendet wird (von hier ab 4 Kommentare gezeigt)? Dieses Projekt verwendet autotools und ist daher in der Portabilität auf Plattformen beschränkt, die vom Toolset unterstützt werden. Die Verwendung des autotool's Installationsskripts ist daher die natürlichste und portabelste Lösung für alle Plattformen, auf denen das Projekt mit den bereitgestellten Makefiles aufgebaut werden kann.

@sgbeal Ich kann das Problem zwar immer noch nicht finden, genauer ansehe , scheint es Windows zu unterstützen. Unter Windows ist mkdir ein Alias ​​für md , das -p nicht unterstützt.

Vielleicht senden Sie eine PR, die MKDIR unter Windows anders setzt als unter Nicht-Windows?

Viele Details unten. Ich kenne mich mit dem Problem nicht so gut aus, aber ich habe es immer wieder gesehen.

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 was ist ein "Windows"?

Der Build verwendet die Autotools und sollte "wirklich" das install-sh verwenden, das mit Autotools verteilt wird. Wenn _dieses_ Installationsprogramm nicht portabel genug ist, ist die Verwendung der Autotools eine verlorene Sache.

@sgbeal Das eingecheckte Makefile wird nicht von Autotools generiert. Es ist eine alternative Möglichkeit zum Erstellen, wenn Autotools möglicherweise nicht verfügbar sind (zB wenn dies für eine C-Erweiterung für Ruby oder Python kompiliert wird).

"Windows" ist in diesem Fall, wenn Sie zB gcc und gmake haben, es aber von CMD ausführen (im Gegensatz zB zu Cygwin Bash oder einer ähnlichen POSIX-Umgebung).

Unabhängig davon denke ich, dass mein #2728 PR dieses Problem behebt, da mit diesem PR make nicht mehr versuchen sollte, bereits vorhandene Verzeichnisse zu erstellen.

@xzyfer Danke! Sieht so aus, als hätte ich richtig vermutet, dass es hier speziell um die Windows-Kompatibilität geht. Gesendet #2728, was einfach make daran hindern sollte, bereits vorhandene Verzeichnisse zu erstellen.

@glebm meine aufrichtige Entschuldigung: 'was ist ein "Windows"' war scherzhaft gemeint (Windows ist seit letztem Jahrtausend kein