LLVM n'est pas encore stable (c'est d'ailleurs embêtant si la compatibilité du bytecode d'une version à une autre est cassée), mais il me semble qu'ils assurent que leur bytecode est indépendant de l'architecture.
À mon avis, le problème se situera plutôt du côté des applis "mal codées" (ce qui est relatif) qui ne sont déjà que difficilement portables comme ça (donc celles qui n'utilisent pas des sizeof(void *), ou qui ne font pas attention à l'endianess, etc).
À la limite, on pourra proposer des paquets spéciaux dépendants d'une architecture qui pose problème pour ces paquets (si foobar marche sur tout sauf sur ARM, on propose le paquet précompilé pour ARM).
Ensuite, la compilation est faite : le plus difficile et le plus lourd est la transformation des sources vers le bytecode (parsage des fichiers d'en-tête, optimisations, etc). Du côté client, il ne faut que générer le fichier assembleur, l'assembleur et le lier.
Pour le test de Cream, la phase "compilation sur le serveur" prend environ 20 secondes (peut-être plus, je ne m'en souviens plus), et compiler le bytecode en code natif prend moins d'une seconde. À mon avis, compiler une vingtaine de gros paquets devrait prendre moins de 30 secondes, en tous cas moins d'une minute.
Compiler KDE depuis les sources, ça prend combien de temps ? 3h chez moi. On y gagne donc si le bytecode s'assemble en moins de 3h (bon, ce n'est pas instantané, mais on installe bien moins souvent un programme qu'on ne l'utilise).
[^] # Re: Pas très écolo
Posté par steckdenis . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 1.
À mon avis, le problème se situera plutôt du côté des applis "mal codées" (ce qui est relatif) qui ne sont déjà que difficilement portables comme ça (donc celles qui n'utilisent pas des sizeof(void *), ou qui ne font pas attention à l'endianess, etc).
À la limite, on pourra proposer des paquets spéciaux dépendants d'une architecture qui pose problème pour ces paquets (si foobar marche sur tout sauf sur ARM, on propose le paquet précompilé pour ARM).
Ensuite, la compilation est faite : le plus difficile et le plus lourd est la transformation des sources vers le bytecode (parsage des fichiers d'en-tête, optimisations, etc). Du côté client, il ne faut que générer le fichier assembleur, l'assembleur et le lier.
Pour le test de Cream, la phase "compilation sur le serveur" prend environ 20 secondes (peut-être plus, je ne m'en souviens plus), et compiler le bytecode en code natif prend moins d'une seconde. À mon avis, compiler une vingtaine de gros paquets devrait prendre moins de 30 secondes, en tous cas moins d'une minute.
Compiler KDE depuis les sources, ça prend combien de temps ? 3h chez moi. On y gagne donc si le bytecode s'assemble en moins de 3h (bon, ce n'est pas instantané, mais on installe bien moins souvent un programme qu'on ne l'utilise).