2017-08-22 5 views
1

J'utilise actuellement le Yocto Pyro et j'écris une recette pour construire mon logiciel. J'utilise "repo android" pour gérer mes codes sources de différents dépôts git.Yocto prend-il en charge l'utilisation de "repo: //" dans SRC_URI d'une recette

et de la documentation Yocto, j'ai trouvé il y a 2 solutions pour prendre en charge plusieurs référentiels en SRC_URI: 1. utiliser plusieurs référentiels git dans SRC_URI 2. Utilisation "repo: //" dans SRC_URI

Je suis allé à travers toutes les recettes de méta-openembedded et poky, seules les options 1 peuvent être trouvées dans les recettes existantes (par exemple dvb-apps_1.1.1.bb). J'essaie d'utiliser "repo: //" pour ma recette et j'ai trouvé le problème suivant: La commande "repo" n'est pas disponible dans Yocto, et elle ne peut pas utiliser la commande "repo" de l'hôte.

Pour résoudre ce problème, je tends la base.bbclass pour soutenir "repo: //" (en ajoutant suivant): elif scheme == "repo": d.appendVarFlag('do_fetch', 'depends', ' repo-native:do_populate_sysroot')

et ajouter ce qui suit à mon local.conf: ASSUME_PROVIDED += "repo-native" HOSTTOOLS += "repo"

Ensuite, Je suis arrivé à un problème, il ne déclenchera pas la reconstruction de ma recette lorsque le référentiel manifeste est modifié. Le [repo.py] (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/repo.py?h=pyro) ne supporte pas les choses comme SRCREV, SRCPV.

Quelqu'un pourrait-il aider? Merci d'avance.

+1

Un changement manifeste n'est-il pas une bonne raison de faire une reconstruction? Ou essayez-vous de suivre une repo-branche non-maître? En ce qui concerne le repo qui semble ne pas être utilisé: c'est vrai, le fetcher n'a pas eu de commit (non-deprecation) depuis de nombreuses années ... – jku

+1

@jku, désolé que j'ai fait une grosse erreur dans la description, je voulais dites "ça ne va pas se déclencher". J'ai corrigé la description. – BenKwan

+0

Il serait intéressant de voir comment vous avez étendu base.bbclass – urnenfeld

Répondre

0

Vous pouvez corriger le comportement en définissant le point de SRCREV à la tête, mais étant dans rikiki la mise en œuvre de mise en pension comme:

def supports_srcrev(self): 
    return False 

Je ne vois pas d'autre choix que de forcer la tâche chercher comme:

bitbake recipe -c fetch -f