Jump to content

[DEV][TOOL]CyanoS2


Recommended Posts

Bonjour tout le monde,

Pour ceux qui sont intéresser par le compilation de leurs propres rom Cyanogen,

Je vous propose un petit programme en batch / shell pour linux (compatible Ubuntu pour l’installation des deb nécessaires pour les autres distributions ré-ferrez vous au wiki cyanogen pour les packages a installer) .

https://github.com/mik3/CyanoS2

Sur le github vous avez une page issues, servez vous de cette page pour remonter les bugs du script.

Ce script ne sert que pour le GALAXY S2.

Il synchronise tout les dépôts mais pour les reste du scripts c'est spécifique au S2

Edited by m!k3
  • Like 4
Link to comment
Share on other sites

Oui c'est pour compiler des roms CM7/9, mais je le mets pas dans ton topic vu que c'est ma création, mais tu peux mettre un lien dans ton topic vers le miens. Mais c'est uniquement pour les utilisateurs Linux

Link to comment
Share on other sites

@M!k3 , cool , merci ;)

Je compte sur toi pour me remonter des bugs et des idées d'amélioration ;)

@m!k3 : Oh, excuse-moi, je ne savais pas que c'était ton travail.

Pas grave je ne l'avais pas préciser

Link to comment
Share on other sites

En réalité, je ne vois pas de logique dans la compilation / un orde d'une ROM, c'est pas par exemple comme en mécanique ou là il y a une vrai logique / un orde ou même en électricité. Ici dans la compilation, c'est tellement bizarre que je ne trouve pas de mots pour décrire ça. Je veux dire qu'il n'y a pas un ordre précis dans l'exécution dès manoeuvres pour compiler une ROM, comme dans la construction d'un circuit électrique ou il y a tout bien détaillé et facile a comprendre.

Link to comment
Share on other sites

Beau boulot ;) , mais tu devrais externaliser les fonctions et sourcer ensuite dans chaque scripts , ça gagnerais en lisibilité et en maintenance

que veux tu dire par externaliser?

Link to comment
Share on other sites

@m!k3 , externaliser les fonctions , c'est les mettre dans un fichier à part : "fonctions.inc" par exemples , et ensuite dans chaque scripts tu source ce fichier , comme ça : "source fonctions.inc" , l'intérêt est de centraliser toutes les fonctions , si par exemple du doit modifier une fonctions qui est présente dans plusieurs scripts tu ne modifie qu'une fois , dans le fichier fonctions.inc , j'ai vu par exemple que à pas mal d'endroit tu utilises :

echo "Appuyer sur ENTER pour continuer"

read enterKey

tu peux très bien faire une fonction comme ça :

pause()

{

read -p "$*"

}

ensuite tu l'utilise comme ça :

pause 'le texte que tu veux'

ok, ok je chipote ;) , mais j'ai pas mal développé de shell scripts dans ma carrière et je suis très fan des fonctions :lol:

Autres choses , tout tes chemins présent dans tes scripts

~/Cyanogen/CM9/

~/Cyanogen/CM7/vendor/cyanogen

tools/up_env_CM7

tools/up_prios2_CM9

etc...

moi je les mettrais dans des variables d'environnements , dans aussi un fichier à part , qu'il faudra également sourcer , comme ça si tu décides de changer les chemins tu ne modifie que les variables et pas tout les scripts

exemple :

CM9=~/Cyanogen/CM9/

export CM9

puis dans ton script :

mkdir -p ${CM9} &&

cd ${CM9} &&

en tout cas tu as sacrément bien bossé , bravo ;)

Link to comment
Share on other sites

@m!k3 , externaliser les fonctions , c'est les mettre dans un fichier à part : "fonctions.inc" par exemples , et ensuite dans chaque scripts tu source ce fichier , comme ça : "source fonctions.inc" , l'intérêt est de centraliser toutes les fonctions , si par exemple du doit modifier une fonctions qui est présente dans plusieurs scripts tu ne modifie qu'une fois , dans le fichier fonctions.inc , j'ai vu par exemple que à pas mal d'endroit tu utilises :

echo "Appuyer sur ENTER pour continuer"

read enterKey

tu peux très bien faire une fonction comme ça :

pause()

{

read -p "$*"

}

ensuite tu l'utilise comme ça :

pause 'le texte que tu veux'

ok, ok je chipote ;) , mais j'ai pas mal développé de shell scripts dans ma carrière et je suis très fan des fonctions :lol:

Autres choses , tout tes chemins présent dans tes scripts

~/Cyanogen/CM9/

~/Cyanogen/CM7/vendor/cyanogen

tools/up_env_CM7

tools/up_prios2_CM9

etc...

moi je les mettrais dans des variables d'environnements , dans aussi un fichier à part , qu'il faudra également sourcer , comme ça si tu décides de changer les chemins tu ne modifie que les variables et pas tout les scripts

exemple :

CM9=~/Cyanogen/CM9/

export CM9

puis dans ton script :

mkdir -p ${CM9} &&

cd ${CM9} &&

en tout cas tu as sacrément bien bossé , bravo ;)

Merci merci, mais je ne suis qu'un novice aussi moi dans le shell...

et j'ai quand même mis 2 jours pour faire ca lol

pour les fonctions c'est pas une mauvaise idées, mais je vais devoir me documenter avant

Link to comment
Share on other sites

Bon comme je vois qu'il y a plusieurs connaisseurs ici, je pose une question. Quand j'ai essayé de supprimer les Launcheurs et applications inutile, j'ai aperçu certaines applications en double et les applications en double avaient le mot " vendor " dans leur nom juste avant " apk ". Comme je vois que vous avez le même mot dans vos codes là, ma question est la suivant, il veut dire quoi ce mot et il représente quoi ?

Link to comment
Share on other sites

des apk avec vendor?

ici dans le script vendor c'est les dossier qui contient tout ce qui est spécifique a un modèle de téléphone donc rien a voir avec les apk lol

mais si tu veux du style com.vendor.xxxx.xxx.apk c'est pas pcq tu as vendor dans le nom de l'apk que c'est le même

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...