L'utilisation de mkdir est revenue plusieurs fois et a été rejetée car elle n'est pas
portable. Nous sommes ouverts aux solutions portables.

Le lundi 12 novembre 2018, 18h55, Stephan Beal < [email protected] a écrit :

l'installation échoue car $(PREFIX)/lib existe déjà

[ stephan@host :~/cvs/libsass]$ m install PREFIX=$HOME
mkdir /home/stephan/lib
mkdir : impossible de créer le répertoire '/home/stephan/lib' : le fichier existe
Makefile:263 : la recette pour la cible '/home/stephan/lib' a échoué
make: * [/home/stephan/lib] Erreur 1

Le correctif est trivial : utilisez mkdir -p au lieu de mkdir.

C'est le même que #1992 https://github.com/sass/libsass/issues/1992 ,
mais ce ticket est inexplicablement fermé.

PS : lorsque vous essayez d'utiliser la version générée par autotools, en exécutant autoconf
pour convertir configure.ac en configure, le ./configure résultant échoue
car:

[ stephan@host :~/cvs/libsass]$ ./configure --prefix=$HOME
configure : erreur : impossible de trouver install-sh, install.sh ou shtool dans le script "."/script

J'utilise donc le makefile qui est archivé dans l'arborescence, plutôt que
celui généré par autotools (alias GNU "Auto, my ass!" Tools).

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/sass/libsass/issues/2727 , ou désactiver le fil
https://github.com/notifications/unsubscribe-auth/AAjZWC46FJREYZk3iPIdWpGiuKuKlkJ4ks5uuSlkgaJpZM4YZIEz
.

Certes, mkdir -p est plus portable que de simplement ne pas s'installer sur n'importe quelle plate-forme ?

Voici une solution portable, tirée du manuel d'autotools :

Depuis la caisse 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

Ce script d'installation est aussi portable que possible. (Jetez simplement tous les autoreconf sortie en dehors de ce fichier, puis archivez ce fichier.)

Curieusement, il utilise mkdir -p (qui est apparemment spécifié par POSIX mkdir), mais il contourne également divers problèmes de portabilité.

A propos de la portabilité : le code source utilise C++0x, ce qui signifie qu'il se compile sur une plateforme relativement récente (moins de 10 ans). Je parierais mon testicule gauche que toutes ces plates-formes prennent en charge mkdir -p .

Tout a été expliqué en détail plusieurs fois dans tous les précédents
problèmes fermés. Nous allons considérer un pr qui répond aux préoccupations qui ont
été soulevée auparavant.

Le lundi 12 novembre 2018, 20h13, Stephan Beal < [email protected] a écrit :

A propos de la portabilité : le code source utilise C++0x, ce qui signifie qu'il est
compilation sur une plateforme relativement récente (moins de 10 ans). je parierais
mon testicule gauche que toutes ces plates-formes prennent en charge mkdir -p.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/sass/libsass/issues/2727#issuecomment-437808279 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAjZWDztL9XVhyClKwxTr7QVoEu2Oie3ks5uuTvQgaJpZM4YZIEz
.

@xzyfer Pouvez-vous s'il vous plaît

J'aimerais lire la discussion pour comprendre les revendications de non-portabilité, car la prise en charge de mkdir -p est une exigence POSIX : http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mkdir.html

Quelle limitation perçue n'est _pas_ résolue en utilisant le script d'installation généré par autoconf (démontré 4 commentaires à partir d'ici) ? Ce projet utilise le autotools et sa portabilité est donc limitée aux plates-formes prises en charge par l'ensemble d'outils. L'utilisation du script d'installation autotool's est donc la solution la plus naturelle et la plus portable pour toutes les plateformes sur lesquelles le projet peut être construit à l'aide des makefiles fournis.

@sgbeal Bien que je ne trouve toujours pas le problème, en regardant plus loin le Makefile, il semble prendre en charge Windows. Sous Windows, mkdir est un alias pour md , qui ne prend pas en charge -p .

Peut-être envoyer un PR qui définit MKDIR différemment sur Windows et non-Windows ?

De nombreux détails ci-dessous. Je ne connais pas bien le problème mais je l'ai vu revenir maintes et maintes fois.

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 qu'est-ce qu'un "Windows" ?

Le build utilise les autotools et il "devrait vraiment" utiliser l'install-sh qui est distribué avec autotools. Si _ce_ programme d'installation n'est pas assez portable, l'utilisation des outils automatiques est une cause perdue.

@sgbeal Le Makefile

"Windows" dans ce cas, c'est quand vous avez par exemple gcc et gmake mais que vous les exécutez à partir de CMD (par opposition à par exemple Cygwin Bash ou un environnement POSIX similaire).

Quoi qu'il en soit, je pense que mon PR #2728 résout ce problème, car avec ce PR make ne devrait plus tenter de créer des répertoires qui existent déjà.

@xzyfer Merci ! On dirait que j'ai deviné qu'il s'agit spécifiquement de la compatibilité Windows. Envoyé #2728 qui devrait simplement empêcher make d'essayer de créer des répertoires qui existent déjà.

@glebm mes plus sincères excuses : « qu'est-ce qu'un « Windows » » était destiné à la facétie (Windows n'a pas été une chose dans ma maison depuis le millénaire dernier), pas comme une question honnête, et cela n'a pas sa place dans ce forum.