2017-10-16 5 views
0

J'ai beaucoup utilisé Buildroot au fil des ans et j'ai toujours réussi à trouver des solutions aux obstacles que j'ai rencontrés. Mais celui-ci me fait tourner en rond.Pourquoi Buildroot ne fournit-il pas de cible pour un paquet hôte spécifique au projet ajouté à la construction par procédure?

J'ai ajouté un outil python git-source en tant que paquet hôte à ma build Buildroot pour une cible ARM. J'ai terminé le travail sur le paquet/Config.in.host et le paquet/toolname/Config.in.host ainsi que les fichiers package/toolname/toolname.mk. Tout semble être en ordre. J'ai comparé le travail avec les résultats de l'add_new_package.wizard.

La nouvelle option apparaît dans menuconfig.

Il n'est pas disponible en tant que cible, même si j'ai des paquets côté cible que j'ai inclus qui sont des cibles valides. c'est-à-dire que je peux exécuter: make-side-package-name et ces paquets sont construits très bien.

Je ne peux pas exécuter: de faire le nom de paquet-côté-côté car j'obtiens l'erreur "Aucune règle pour faire la cible".

Il doit donc y avoir quelque chose que je fais de façon incorrecte avec le paquet hôte, bien que je fasse clairement les choses avec les paquets cibles. Tout indique que Buildroot ignore simplement mon paquet hôte, autre que de le coller dans le menu menuconfig. Mes heures de recherche sur les sites Web ont conduit à pas un seul article sur quelqu'un ayant ce même problème. Il me manque quelque chose d'évident, je pense. Ma question est - quel débogage puis-je faire, où puis-je chercher pour savoir ce qui empêche Buildroot de reconnaître correctement mon nouveau paquet?

EDIT: Je crois comprendre maintenant qu'une partie du problème est l'ordre de construction, et peut-être que je peux résoudre un problème avec des directives de dépendance. Mon paquet cible qui repose sur le paquet hôte a été construit en premier. J'avais supposé que le bon sens dicterait que les paquets hôtes seraient traités en premier, mais ce n'est apparemment pas vrai.

EDIT: affichage du fichier .mk

TOOLNAME_VERSION = 2 
TOOLNAME_SITE = $(call github,devname,toolname,$(TOOLNAME_VERSION)) 
TOOLNAME_SETUP_TYPE = setuptools 
TOOLNAME_LICENSE = GPL-3.0 
TOOLNAME_LICENSE_FILES = LICENSE 

HOST_TOOLNAME_DEPENDENCIES = host-python-library 

$(eval $(host-python-package)) 

TOOLNAME = $(HOST_DIR)/usr/bin/toolname 

Comme je l'ai laissé entendre avant, il est maintenant en cours d'exécution très bien donc je sais qu'il est la plupart du temps mis en place correctement, le problème restant est la cible de make est manquante. Selon le manuel Buildroot, je devrais en avoir un disponible.

J'ai maintenant découvert que la cible de rendu manquante rendait impossible la construction d'autres paquets dépendant de celle-ci. La génération du package dépendant échoue maintenant parce que "No rule to make" sur le package de l'outil dont il dépend dépend de TARGET_PACKAGE_DEPENDENCIES = nom de l'outil

+0

La liste de diffusion et le canal IRC sont les meilleurs endroits pour de telles questions. Vous trouverez de meilleures réponses là-bas. Aussi votre question est assez vague: pouvez-vous fournir vos fichiers Config.in et .mk (peut-être obscurcir les données sensibles)? –

+0

Merci pour la suggestion. J'ai posté le .mk, il n'y a vraiment rien d'intéressant dans le fichier Config.in.host c'est simple et le paquet apparaît dans menuconfig et est construit correctement. C'est juste le problème de cible qui me dérange maintenant. –

Répondre

0

Hallelujah! La réponse est que le nom de la cible n'est PAS nom de l'outil, mais est plutôt nom de l'outil hôte. La cause profonde du problème est le manque de mention de cette nuance dans la section 8.12.5 de la documentation de Buildroot. Je suis tombé sur la réponse tout en recherchant des dépendances de paquet dans le chapitre 17, où il identifie l'utilisation appropriée pour ce cas spécifique.

1

Pouvez-vous publier votre toolname.mk? Il semble que vous ayez oublié d'ajouter la ligne $ (eval $ (host-python-package)).

+0

Il est là, merci pour la conjecture. –