Bazel: Utiliser swig à partir d'un emplacement non standard

Question

Parce que je n'ai pas d'accès root sur ma machine, j'ai construit et installé swig à partir de la source dans un répertoire non-standard (/scratch/swig/build) et je veux que bazel l'utilise. Alors, quand j'essaie de construire tensorflow, je reçois l'erreur que rasade ne peut pas être trouvé:

INFO: Found 1 target... 
INFO: From SWIGing tensorflow/python/tensorflow.i: 
bazel-out/host/bin/tensorflow/swig: line 17: swig: command not found 

Vérification du script swig mentionné dans l'erreur, il est juste un script qui fait:

#!/bin/bash 
swig "$@" 

Impression du $PATH de ce script montre qu'il est:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:. 

Je ne peux pas ajouter la variable $ PATH dans le script rasade, car il se refaisait sur la construction. Alors, comment puis-je dire à bazel d'utiliser mon emplacement de swig non standard?

Answer 1

Ce n'est pas Bazel spécifique, il fait partie du code tensorflow:

https://github.com/tensorflow/tensorflow/blob/master/tensorflow/tools/swig/swig.sh

Vous pouvez simplement modifier ce fichier avant de construire.

La règle de construction spécifique qui utilise ce fichier est également défini par tensorflow, puisque ce n'est pas une règle inclus dans la distribution Bazel de base:

https://github.com/tensorflow/tensorflow/blob/master/tensorflow/tensorflow.bzl#L275

Answer 2

Ce problème ressemble à cela est dû à Bazel Sandboxing.

Si oui, en utilisant les options suivantes Bazel devrait contourner le problème, comme il se sandboxing off:

--spawn_strategy=standalone --genrule_strategy=standalone 

Je n'ai pas testé, cependant.

Ce blog post explique:

sandboxing est la technique de restreindre les droits d'accès d'un processus . Dans le contexte de Bazel, nous sommes principalement préoccupés par restreignant l'accès au système de fichiers. Plus précisément, le système de fichiers de Bazel contient uniquement des entrées connues, de sorte que les compilateurs et autres outils ne peuvent même pas voir les fichiers auxquels ils ne devraient pas accéder.

Comment ça fonctionne sur Linux:

Sur Linux, nous utilisons les espaces de noms d'utilisateurs, qui sont disponibles sous Linux 3.8 et versions ultérieures. Plus précisément, nous créons un nouvel espace de noms de montage. Nous créons un répertoire temporaire dans lequel nous montons tous les fichiers que le sous-processus est autorisé à voir. Nous utilisons ensuite pivot_root pour que le répertoire temporaire apparaisse en tant que répertoire racine pour tous les sous-processus.

Nous montons également/proc,/dev/null,/dev/zéro, et un système de fichiers temporaire (tmpfs) sur/tmp. Nous montons/dev/random et/dev/urandom, mais nous recommandons pour leur utilisation, car cela peut conduire à des constructions non reproductibles.

Nous montons actuellement/bin,/etc,/usr (sauf/usr/local), et chaque répertoire commençant par/lib, pour permettre l'exécution d'outils locaux. Dans l'avenir, nous prévoyons de fournir un shell avec un ensemble d'utilitaires Linux , et d'exiger que tous les autres outils sont spécifiés comme entrées .

Bazel's roadmap dit que sandboxing sur MacOSX est prévue pour Avril 2016.

sandboxing est censé être une bonne chose, car il garantit que les règles construire sont compatibles (comme toute dépendance qui ne soit pas explicité bomberez). Ainsi, au lieu d'arrêter le sandbox, les meilleures solutions seraient peut-être:

• de fixer les règles de construction de TensorFlow pour rendre la dépendance à swig explicite.
• ou de rendre le swig disponible dans l'un des répertoires ci-dessus (par exemple /bin).
• ou de configurer explicitement Bazel pour monter le répertoire dans lequel swig vit (si possible avec -M et -m, je n'ai pas encore testé).

Espérons que cela aide.