Vérification de l'architecture avec Bazel-Skylark

Question

J'essaye de construire Tensorflow dans ppc64le depuis la source sur un commit assez récent mais je suis en train de trébucher sur quelques problèmes (https://github.com/tensorflow/tensorflow/issues/10306 et https://github.com/bazelbuild/rules_closure/issues/207) qui proviennent de bazebuild/rules_closure.

La plupart du temps, j'ai besoin de vérifier si la machine cible est ppc64le (est-ce qu'il y a une façon native de Bazel d'exécuter quelque chose comme uname -m?). Ensuite, nous ne devrions pas passer '-client' aux appels JVM - malheureusement, à ce jour, il n'y a pas de support pour le compilateur C1 (client) dans openjdk8 pour ppc64le.

Il existe également des binaires x64 préconfigurés (nodejs et protoc) téléchargés lors de la construction de rules_closure - qui est antérieur à la portabilité. Je veux savoir s'il existe un moyen de contourner ce problème, comme d'ajouter des liens vers un référentiel contenant des binaires ppcle64 ou de revenir aux binaires du système.

(J'ai également demandé ceci dans la liste de diffusion Bazel-discuss)

Answer 1

Pourquoi le drapeau -client nécessaire? Pourrait-il être supprimé pour toutes les architectures? Le mode intégré de Bazel pour ajuster la configuration du JDK est le java_toolchain() rule (vous pouvez voir le default java_toolchain que Bazel utilise dans le référentiel source). Si le drapeau est vraiment nécessaire sur certaines plates-formes mais pas sur d'autres, alors un java_toolchain devrait être ajouté, et les plates-formes qui ne supportent pas cet indicateur peuvent utiliser une chaîne d'outils personnalisée sans le drapeau.

En ce qui concerne les binaires, le seul choix disponible maintenant pour utiliser la règle select(), en vérifiant le paramètre host_cpu, pour choisir un binaire qui fonctionnera sur la plate-forme locale.

Je travaille activement sur une nouvelle fonctionnalité appelée Platforms for Bazel (le design doc est publiquement disponible). Cela permettra à des projets tels que TensorFlow ou rules_closure de définir les plates-formes qu'ils prennent en charge et de fournir différentes chaînes d'outils et configurations, incluant éventuellement des éléments tels que les binaires de protocoles et les drapeaux JDK. Malheureusement, alors que le développement se passe bien, la mise à jour des règles Java natives prendra du temps. Vous pouvez suivre la progression sur Github au numéro #2219.