En effet, Yocto doit être utilisé par un rôle spécifique dans l'équipe de développement : celui du responsable de la distribution et du packaging.
Les développeurs n'ont pas besoin de se frotter directement à Yocto. Il "suffit" de générer un SDK et de leur fournir, afin qu'ils configurent et compilent leurs développements avec le même environnement que celui qu'ils trouveront sur la cible.
Après installation du SDK, le développeur source un fichier de définition de l'environnement, puis effectue son cycle ./configure, make dans l'environnement Yocto, mais sans avoir à toucher des recettes ou utiliser bitbake.
Si le développement cible une architecture Intel, il est possible de se passer de Yocto : développer en natif en s'assurant que l'on n'a pas de lien dur avec le PC de dév. (autotools bienvenus), puis lorsque c'est au point livrer le code source au packager qui l'intègre dans Yocto. Personnellement j'accompagne des clients qui bossent comme cela.
Encore faut il s'assurer que les différences de version entre le PC de développement et l'image finale générée par Yocto n'induisent pas de problème lors de l'intégration sur la cible.
Si par contre on cible une architecture non Intel, se replier sur le PC de développement n'est pas possible puisqu'il faut tester en croisé. Le SDK devient alors la solution.
Concernant les prérequis, c'est une erreur lors de la mise en ligne du programme. Merci de l'avoir signalé, je fais rectifier.
[^] # Re: 3615 MaLife
Posté par Cch . En réponse à la dépêche Atelier « Concevoir un système embarqué Linux avec Yocto » en octobre 2015. Évalué à 1.
En effet, Yocto doit être utilisé par un rôle spécifique dans l'équipe de développement : celui du responsable de la distribution et du packaging.
Les développeurs n'ont pas besoin de se frotter directement à Yocto. Il "suffit" de générer un SDK et de leur fournir, afin qu'ils configurent et compilent leurs développements avec le même environnement que celui qu'ils trouveront sur la cible.
Après installation du SDK, le développeur source un fichier de définition de l'environnement, puis effectue son cycle ./configure, make dans l'environnement Yocto, mais sans avoir à toucher des recettes ou utiliser bitbake.
Si le développement cible une architecture Intel, il est possible de se passer de Yocto : développer en natif en s'assurant que l'on n'a pas de lien dur avec le PC de dév. (autotools bienvenus), puis lorsque c'est au point livrer le code source au packager qui l'intègre dans Yocto. Personnellement j'accompagne des clients qui bossent comme cela.
Encore faut il s'assurer que les différences de version entre le PC de développement et l'image finale générée par Yocto n'induisent pas de problème lors de l'intégration sur la cible.
Si par contre on cible une architecture non Intel, se replier sur le PC de développement n'est pas possible puisqu'il faut tester en croisé. Le SDK devient alors la solution.
Concernant les prérequis, c'est une erreur lors de la mise en ligne du programme. Merci de l'avoir signalé, je fais rectifier.