steckdenis a écrit 327 commentaires

Normalement.

Je n'ai pas testé, mais ça ne devrait pas casser. Pour le moment, ça ferait une boucle infinie (code minimal sans rien), mais dans quelques minutes, j'aurai intégré un truc qui fait qu'on ne demande pas l'installation d'un paquet déjà en attente d'installation :

* On demande libgcc1
* On a besoin de libc6
* Libc6 a besoin de libcc1, mais il est déjà dedans, on retourne.

Ca devrait aller :) . Merci beaucoup pour les liens (Debian a vraiment un univers encore plus grand que ce que je pensais autour de lui !)

C'est avec un grand plaisir que j'apprends que Pacman sait le faire ! Il me semblait avoir lu (et peut-être même dans la doc de libalpm) que Pacman ne sait pas. Il semblerait que les choses se soient arrangées.

Pour les dépendances inverses, je fais au plus simples. Ce sont en fait des dépendances normales, gérées comme telles. La différence est qu'elles sont calculées par une grosse fonction revdep() dans databasewriter.cpp. Voici ici pour le code : http://wiki.logram-project.org/websvn/listing.php?repname=Lo(...) .

Merci pour les encouragements :) .

C'est tout ce que j'ai à dire.

Il y a maintenant quelques mois, j'ai testé Wormux SVN, et son moteur physique. Franchement, c'est super ! Par exemple, quand les cadeaux tombent, ils se mettent à rouler, dégringoler, etc.

Par contre, oui, c'est bourré de petits bugs (dont un que j'ai essayé de résoudre moi-même, mais je n'ai pas réussi). Par exemple, pour certains personnages et aléatoirement, toutes les balles qu'ils tirent ne touchent personne (elles traversent l'équipe adverse).

Par contre, s'il est encore d'actualité (je dois tester), il y en a un autre que j'ai failli résoudre :

* Démarrer Wormux
* Faire une partie, et utiliser au moins une fois le bazooka ou toute arme qui nécessite un chargement
* Appuyer sur le menu ESC, ou quitter le jeu. Bref, n'importe quelle action qui interromp/quitte le jeux provoque le bug
* Retourner au jeu (ou créer une nouvelle partie)
* Utiliser le bazooka ou toute arme qui se charge

Le bug est le suivant : la barre de chargement ne se remplit plus. On peut rester appuyé aussi longtemps qu'on veut sur ESPACE, rien ne bouge. Si après quelque temps, en arrête cet appui, notre personnage se fait par exemple atomiser par son propre bazooka (c'est comme si on n'avait appuyé qu'une fraction de seconde).

J'ai trouvé l'endroit dans le code qui gère ça, mais je n'arrive pas à voir ce qui coince. Je dois encore tester avec une version SVN récente, sur plusieurs machines, pour voir si je rapporte le bug (comme dit plus haut, j'ai plus testé depuis des mois). Si vous testez vous, et que le bug se produit dans une version récente, vous pouvez le rapporter pour moi (moi et l'anglais...) ;-) .

A part ça, c'est tout bon :D !

Je sais que KDE ne fait pas tout, mais je le prend comme exemple. aMSN est très bien, sauf qu'il ne gère que MSN (et que, personnellement, je trouve Kopete plus beau et plus facilement thémable).

Je n'ai jamais, mais alors jamais traité KDE de distrib.

Oui, Kubuntu est Ubuntu. Ce que je voulais dire, c'est que un Ubuntu avec KDE est un peu mieux, non-pas parce que Kubuntu utilise KDE, simplement parce qu'on n'a pas tout le "travail" de Ubuntu dedans, toute cette simplification, et cette suppression de fonctionnalité. Sous Ubuntu (GNOME), on utilise soit Synpatic qui est effrayant, soit Gnome-app-install qui est trop simpliste. Avec Kubuntu, on utilise KPackageKit qui est élégant, simple mais très complet.

Franchement, où t'as vu que je parlais de distribs ? o_O

Bonjour,

* PlayOnLinux. Ta distrib peut te mettre une icône sur le bureau. Tu cliques dessus, tu peux installer un jeu (faut cliquer sur «+» puis attendre), et les jeux se lancent en un clic. Tu peux même directement mettre un raccourcis de ce jeu sur ton bureau. Parmis les jeux supportés : WoW, CounterStrike, Half Life, les Sims, etc (y'en a plus de 100)

* Purée, ces GNOMEistes m'énnervent ! Passez donc à KDE, et vous verrez ce que Linux peut vous offrir. Désolé, mais avec Kopete, je chat avec qui je veux (IRC, Jabber, MSN avec support WebCam, ICQ, QQ, etc). Avec la suite Kontact, on fait pâlir les Windows Live Essentials, et de loin. Sous GNOME, vous savez, simplement (donc sans rien configurer) avoir les mêmes contacts dans Kopete et KMail ? Vous savez ouvrir un document KOffice directement dans Konqueror ? (sans avoir du le télécharger à l'avance).

* Windows ne marche pas, on cache le travail, c'est tout. Moi j'ai installé Kubuntu à ma mère : rentrer le CD, cliquer sur installer, faire son partitionnement (bon là c'est un peu musclé, mais on doit aussi avec Windows), cliquer sur Installer, ça marche. Installer un logiciel ? K»Configuration du système»Ajout/Suppression de logiciels, une recherche, cliquer sur Installer, ça marche. Une imprimante ? Brancher, ça marche. Un scanner ? Brancher, ça marche. Une webcam ? Brancher, ça marche (même pas besoin de redémarrer Kopete). Un DVD ? Rentrer, choisir «Lire le DVD» dans la fenêtre qui apparaît, ça marche (sous-titres, menus, pistes audio, etc). Désolé, mais sur l'utilisabilité, Linux éclate largement Windows, mais profond ! C'est fous tout de même ! Sous Windows, ça parraît presque normal de devoir installer pour chaque matériel le pilote fourni sur le CD, et quand ça marche pas (vieux pilote, Windows 64 et pilote 32), il faut Googler. N'importe quelle appli Windows nécessite un CD, ou un long et pénible téléchargement après une recherche Google, avec risques de virus. Comme je le disais, plus un produit est bien, au plus facilement on le critique

Bref, tissu de mensonges, ou alors ignorance (ou alors humour ?)

Pour troller, comme d'habitude : Linux ne se résume pas à GNOME, et surtout pas à Ubuntu ! Ils proposent un environnement simple, très simple, trop simple. Ils disent «Linux c'est bien c'est simple», mais éliminent des fonctionnalités critiques. Kubuntu est déjà mieux, mais il y a aussi Debian, Mandriva et OpenSuSE qui font ça très très bien (+1 pour OpenSuSE, ils font de l'excellente intégration)

Avec mon système, c'est possible, mais ça nécessite un hack de gettext :-° (et pas un petit).

Soit des fichiers de langue en anglais, français et espagnol disons.

L'espagnol a défini ses langues comme étant espagnol>français>anglais. Il ouvre un programme (disons KPartitionManager pour que ce soit pas trop trop traduit). Il s'affiche en espagnol, mais les chaînes non-traduites sont en français. Celles qui ne sont pas en français sont en anglais.

Hum, ça va être chaud à faire, il va falloir installer tous les packs langue que l'utilisateur veut :/ . Ca risque d'être bien plus complexe que prévu (j'en ai marre, toutes mes bonnes idées sont trop complexes, LLVM, puis ça maintenant).

Un clavier où il ne faut pas être un utilisateur BAC+5 de Emacs pour taper des trucs genre [], {} et «».

Bref, un truc bien et organisé. J'ai déjà vu des claviers français, c'en est presque marrant tellement que les caractères spéciaux sont mal fait !

Bon, évidemment, il faut savoir se servir du Alt droit, mais c'est assez simple en fait. (Alt droit + W pour avoir «, alt droit + U pour û, alt droit + A pour æ, etc).

Effectivement, mais d'un côté, c'est bien.

Imagine que SuperDistrib empaquette tous ses paquets. Ses devs sont anglais, et ne font pas attention aux traductions. Ils ont fait une erreur, et toutes les traductions sont mauvaises. Un utilisateur francophone va tout voir en anglais, c'est pas bien.

Maintenant, la même SuperDistrib empaquette tous ses paquets, commet l'erreur, mais les devs se retrouvent devant une soupe de nombres. Il est évident qu'ils vont voir quelque-chose, et le corriger.

Dans les deux cas, la coréenne du nord qui n'a jamais vu d'anglais ne sera rien faire des interfaces. Dans le premier, les anglophones ne se seront rendu compte de rien. Dans le deuxième, ils auront corrigé :-) .

Maintenant, un gros problème, c'est si l'utilisateur change sa LOCALE et en met une non-supportée par la distrib (car dans le fonctionnement technique de tout ça, la distrib choisit les langues supportées par les paquets, et copier en.po dans la_langue.po si le paquet ne supporte pas cette lange. C'est un problème à résoudre). Donc, si LOCALE n'est pas bonne, là il y aura un problème. Il faudrait hacker gettext pour utiliser en.po en fallback, voire même proposer à l'utilisateur de classer ses langues dans son ordre de préférence (j'affiche le truc en français, si ça n'existe pas en français, je l'affiche en anglais, sinon en russe, sinon en espagnol, etc).

Pour le premier point, il y a une différence. Ubuntu démarre, demande la langue dans le GRUB (pas moyen de la manquer, le menu est un popup), puis basta.

Effectivement, on a un clavier Français si on a choisi le Français. Bon, c'est bien pour aller sur Internet, mais moi je veux un clavier belge. Néanmoins, pour la michu qui ne fait que taper des lettres, c'est bon comme ça.

Du côté de Mandriva, ils nous demandent le clavier au démarrage, sur fond noir. Si au moins le desktop démarrait en arrière-plan, ça irait, mais non, il faut absolument répondre à ces questions.

Et pour la michu, oui, le clavier Français est sélectionné par défaut. Le problème, c'est que si elle est Québécoise, Belge ou Suisse, ce clavier ne lui conviendra pas. Tu vas me dire que le problème est simplement déplacé ? En fait non. Michu essaie un LiveCD que son fils/neveu/mari lui a trouvé. Avec Mandriva, elle a besoin de cette personne avec quand elle teste, et ne peut donc pas le faire quand elle veut. Avec Ubuntu, elle teste, mais n'installe pas. Il faut de toute façon quelqu'un pour lui faire l'installation, alors autant que ce soit lui, pas elle, qui réponde aux questions.


Pour le deuxième point, en effet, c'est très bien séparé. Néanmoins, la différence est floue. On active les effets graphiques dans le centre de contrôle et dans les options de KDE par exemple. Le panneau de conf de KDE permet de changer la résolution de l'écran (en tous cas sous Debian), le centre de Mandriva aussi. On peut gérer KDM, la gestion de l'énergie, et la gestion des sessions dans le centre de KDE, peut-être pas dans celui de Mandriva.

Je reprends Kubuntu comme exemple, qui a intégré KPackageKit dans le centre de contrôle de KDE, c'est là qu'il a sa place. Effectivement, on ne peut pas comparer les rares outils d'Ubuntu, et l'immensité de configuration que propose Mandriva.

Il me semble avoir essayé ce clic droit, mais ne pas avoir trouvé comment remettre l'ancien.

J'utiliserai la bonne vieille méthode avec la 2010.0 : supprimer le plasmoide de l'ancien menu, et ajouter celui du nouveau :) .

Oui, c'est une clef USB (qui réagit comme un disque dur, donc oui, c'est marketing).

Une TDK Trans-It si tu veux savoir, 2Gio.

J'ai déjà regardé tout ça. J'ai vraiment retourné toute la toile pour trouver un remplacement de Sysvinit.

Je ne me suis pas particulièrement intéressé à ceux-là. Il faut dire que eInit est ouvertement abandonné, et Kyuba ouvertement expérimental (mais sans être développé) et noyé dans un site qui parle de tout sauf de lui.

Bref, ils ne sont pas attirants du tout (et absolument pas connus, contrairement à init-ng).

Sans compter qu'ils sont beaucoup moins documentés (il n'y a qu'à regarder la page de téléchargement de Kyuba : la page standard de téléchargement d'un site basé sur Drupal, juste du code, pas de documentation. On ne sait même pas si le machin utilise des scripts shell ou son propre format).

Un script shell, c'est lent (quand on voit que Debian en passant de Bash à Dash m'a fait gagner 8s au boot, alors que je n'avais que peu de services, ça fait réfléchir).

Et puis, qu'est-ce qu'il y a de mal là-dedans ?


service system/usplash {
exec start = /bin/true;
exec stop = /sbin/initng-usplash-shutdown;
}


C'est simple, rapide à parser, et ça évite de réinventer la roue (pas mal de scripts init standards commencent par une définition de $PATH, contiennent le fameux swtich pour start, stop, reload, etc).

J'ai vu ça aussi, je dois encore tester (mais j'ai entendu vraiment beaucoup de bien sur init-ng, donc on ne peut que se réjouir de voir qu'il existe encore).

D'ailleurs, j'ai Mandriva sur un stick USB, et c'est vrai que ça décoiffe niveau démarrage !

J'ai un serveur dédié qui tourne et qui me rapporte :) (j'ai justement fait un don de 30$ ce matin à initng, objet de mon prochain journal).

Je suis content que l'idée te plaise. En effet, avoir des optimisations spécifique au processeur est un gros plus. Ce qui fait que le amd64 est plus rapide que le i386 n'est pas spécialement le passage en 64bit, mais simplement le fait que amd64 est plus récent, et que pour être compatible amd64, un processeur doit supporter plus d'instructions, qu'un i386 ne supporte pas. Ainsi, on peut utiliser l'argument -mtune de GCC.

Les bibliothèques utiliseront également LLVM, ce sera appliqué à tous les paquets (si ça marche). Ainsi, si je teste sur un Core i7, les bibliothèques multimédia par exemple pourront utiliser les instructions dernier cri SSE4, alors que le paquet Debian, amd64 générique, ne dépasse pas SSE2.

Il y a aussi de subtiles différences entre les processeurs AMD et Intel. Une certaine instruction sera plus rapide sur un proc AMD qu'une autre, alors que ça peut être l'inverse sur du Intel. LLVM, dans sa phase de compilation en binaire, va générer le code optimal pour le processeur.

J'ai également comme idée un support d'un genre de "USE flags" : du côté serveur, on compile le programme avec toutes les combinaisons de USE. Dans le paquet, on place les fichiers bytecode en deux parties :

* Un gros fichier bytecode (créé avec llvm-link) pour ce qui ne change pas en fonction des USE
* De petits bytecode pour ce qui est dépendant des USE/architectures (au cas où des #ifdef traineraient)

À l'installation, en fonction des choix de l'utilisateur, on peut choisir les fichiers bytecode à lier, puis à compiler.

Tout ceci n'est qu'une idée. Il me semble que personne encore n'a pensé à utiliser LLVM pour ça, c'est un sujet très intéressant. Tout ce que je peux demander à ceux qui veulent voir ceci réalisé est de contribuer à LLVM et Clang (le code est simple et beau, on s'y retrouve vite), en particulier pour le C++ (j'ai envie d'avoir KDE compilé avec Clang :-° ).

Effectivement, ça mérite un test :

* sokoban.bc : 10296 octets (tiens, il devait être plus petit, il faut dire que j'ai un peu changé la chaîne de compilation pour utiliser clang à la place de clang-cc)
* sokoban (éxécutable) : 11360 octets

Maintenant, je compresse les deux en LZMA

* sokoban_bin.lzma : 3755 octets
* sokoban_bc.lzma : 8212 octets

Effectivement, ça calme :/ . Plus qu'à tester sur de plus gros programmes, LLVM est vraiment intéressant et on sait en faire quelque-chose.

Mouais, mais un truc n'est pas bien allé avec le bytecode, il est largement plus gros que ce que je dis dans le journal, ce n'est pas normal (j'ai pourtant utilisé opt, donc ça devrait être bon). Je vais refaire des tests.

Yeessssss :D

Rah, Clang est vraiment le meilleur : cet exemple est portable, super, magnifique !

Code C:


#include <stdio.h>
#include <stdlib.h>

typedef struct {
void *buffer;
int machin;
} maStruct;

int main(int argc, char **argv)
{
maStruct *s = (maStruct *)malloc(sizeof(maStruct));

s->machin = 3;
s->buffer = s;

printf("Le buffer est à l'adresse %ld", s->buffer);

return s->buffer == s;
}


On compile en bytecode, puis on lance :


/usr/local/bin/llc -o - -march=x86 test.bc


Et un petit extrait :


movl $8, (%esp)
call malloc


Remarque le "$8", la taille de ma structure, contenant un pointeur.

Maintenant, sans recompiler le code C, je génère l'assembleur pour x86-64 :


/usr/local/bin/llc -o - -march=x86-64 test.bc


Et j'obtiens ceci :


movl $16, %edi
call malloc


Remarque le $16 : ça marche, yeah :D . Le reste est bien en pur 64-bit (ici, on utilise %edi car malloc attend un int, pas un int64).

Bref, +1 pour Clang et LLVM, ils savent ce qu'ils font :) .

PS: J'ai pas vérifié avec llvm-gcc, je n'arrive pas à le compiler.

Bonjour,

Beaucoup d'entre vous se sont inquiétés de la portabilité du bytecode généré par Clang, et utilisé par LLVM.

Il faut dire que le problème est réel, et la doc de Clang très claire, avec un bon exemple : sizeof(void *) est codé en dur dans le fichier .ll

Enfin, c'est ce qui devrait être fait. En effet, dans ce document[1], il est cité quelque-part un warning très intéressant, vraiment très intéressant :


portability.c:4:11: note : sizeof(wchar_t) varies between targets, source is not 'portable'


La ligne de commande d'appel est également très intéressante :


clang -arch ppc -arch linux -fsyntax-only portability.c


Vous avez bien vu, deux architectures sont données. C'est à approfondir, car ça pourrait permettre de dire à Clang «Génère du code portable pour toutes ces architectures», et il trouvera automatiquement ce qui ne va pas (et donc permettra de hacker le code source, et de soumettre un patch :) ).

Affaire à suivre, mais en tous cas, c'est intéressant.

[1] : http://llvm.org/devmtg/2007-05/09-Naroff-CFE.pdf

Avec GCC (sauf s'il sait se compiler lui-même, mais sur une autre machine).

LLVM, ses dépendances, et le kernel seront au moins trois choses compilées avec GCC. Le reste, normalement ça passera (si j'arrive à faire marcher llvm-gcc).

Bonjour,

Non, ça ne casse pas, au contraire. Il faut juste garder à l'esprit que tous les paquets ne passeront pas par LLVM.

* Les fichiers qui sont déjà indépendants de l'architecture, tant mieux. Pourquoi changer ça ?
* Les programmes java utilisent déjà une machine virtuelle et sont déjà indépendants de l'architecture, tant mieux aussi.
* De nouveau, le gestionnaire de paquet permettra d'utiliser LLVM, et ne l'obligera pas :) .

Voilà .

Ça c'est pas LLVM, c'est celui qui a codé son programme qui l'a mal fait.

Même avec un GCC normal, on ne sait pas le compiler out-of-the-box sur d'autres architectures.

LLVM est en fait une sorte de GCC qui sort sous forme de bytecode son interprétation au niveau moyen (donc plus du code source, pas du binaire). Si on sait compiler un fichier source avec GCC sur n'importe quelle architecture, on saura utiliser le fichier bytecode LLVM ainsi. Sinon, même GCC aurait nécessité un hack dans le programme.

Il me semble que tout cela a été bien nettoyé depuis le passage au x86_64, il me semble même que Debian a fait pas mal de boulot là-dessus (faut dire que Debian est les architectures, c'est une belle histoire d'amour :-° ).

Bonjour,

C'est possible, mais alors ceci m'étonne :


$ llc -o - bc.bc -march=ppc32


Donc en ppc32 :


.file "bc.bc"


.text
.global main
.type main, @function
.align 2
main:
mflr 0
stw 0, 4(1)
stwu 1, -16(1)
lis 3, .L.str@ha
la 3, .L.str@l(3)
creqv 0, 0, 0
cror 6, 0, 0
bl printf
li 3, 0
addi 1, 1, 16
lwz 0, 4(1)
mtlr 0
blr
.size main,.-main
.section .rodata.str1.1,"aMS",@progbits,1
.L.str: # '@.str'
.asciz "Salut !"


Maintenant, testons l'ARM, avec le même fichier :


.file "bc.bc"
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1


.text
.globl main
.align 2
main:
str lr, [sp, #-4]!
ldr r0, .LCPI1_0
bl printf
mov r0, #0
ldr lr, [sp], #+4
bx lr
.LBB1_1:
.LCPI1_0:
.long .L.str

.size main, .-main
.type .L.str,%object
.section .rodata.str1.1,"aMS",%progbits,1
.L.str: @ @.str
.size .L.str, 8
.asciz "Salut !"


et pour finir, le x86_64


.file "bc.bc"


.text
.align 16
.globl main
.type main,@function
main: # @main
.LBB1_0: # %entry
subq $8, %rsp
movl $.L.str, %edi
xorb %al, %al
call printf
xorl %eax, %eax
addq $8, %rsp
ret
.size main, .-main
.type .L.str,@object
.section .rodata.str1.1,"aMS",@progbits,1
.L.str: # @.str
.asciz "Salut !"
.size .L.str, 8

.section .note.GNU-stack,"",@progbits


Pour un truc pas portable, ça passe assez bien. À mon avis, cette en-tête est plutôt là pour dire «J'ai été compilé sur cette arch, donc je risque d'être dépendant de ça. Tu connais les différences entre les deux, corrige-les».

Je crois, mais je peux me tromper, que tu n'as pas très bien compris le principe du bytecode.

Ce bytecode est très proche du binaire, juste un niveau au dessus, pour être portable. Voici comment se déroule la création d'un paquet :

* Compilation de chaque fichier .c ou .cpp dans un fichier .ll
* Compilation de chaque fichier .ll en un fichier .bc

Si on devait s'arrêter ici, on aurait effectivement plein de redondance, mais ce n'est pas ce qui est fait :

* Utilisation de llvm-link pour lier tous les fichiers .bc en un seul gros fichier .bc

Voilà, c'est là que tout s'est joué. Le bytecode est comme de l'assembleur : les bibliothèques ne sont pas inclues, on ne perd pas de place. On a juste des "call glib_machin_truc" ou "call machin::truc", mais sans rien d'autres.

Une fois le paquet récupérer, c'est là que la liaison est faite :) . C'est à ce moment qu'on dit «glib_machin_truc est un appel vers la fonction blabla dans la lib machin», donc c'est lié dynamiquement.

Par exemple, voici le Makefile utilisé pour compiler Cream :


SOURCES=main.b bookmarks.b callbacks.b command.b CreamView.b download.b favicon.b ftplib.b history.b ini.b keybindings.b
BINARY=cream
LIBS=-lwebkit-1.0 -lgtk-x11-2.0
INCLUDES=-I/usr/include/gtk-2.0 -I/usr/include/webkit-1.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/libsoup-2.4 -I. -I.. -DPREFIX=\"/usr/local\" -DLOCALEDIR=\"/usr/local/share/locale\" -D_REENTRANT

all: $(SOURCES)
llvm-ld -o all -s $(SOURCES)
# Ici on met dans un paquet, les lignes suivantes sont côté client.
llc -o all.s all.bc
clang -o $(BINARY) all.s $(LIBS)

%.b:%.c
clang-cc $*.c $(INCLUDES) -emit-llvm -o - | llvm-as | opt -std-compile-opts > $*.b

clean:
rm -f *.b

distclean: clean
rm -f all.* $(BINARY)


Et quand je liste le contenu du dossier, on voit ceci :


63564 sep 1 14:36 all.bc
10772 sep 1 14:35 bookmarks.b
19560 sep 1 14:35 callbacks.b
10484 sep 1 14:35 command.b
23392 sep 1 14:35 CreamView.b
5824 sep 1 14:35 download.b
3432 sep 1 14:35 favicon.b
23176 sep 1 14:35 ftplib.b
10256 sep 1 14:35 history.b
5808 sep 1 14:36 ini.b
7524 sep 1 14:36 keybindings.b
17804 sep 1 14:35 main.b


On voit qu'il y a des données qui sont perdues entre la somme des tailles des fichiers .b, et la taille du .bc. Ce sont les répétitions qui sont éliminées.

J'ai vu plein de #ifdef, dans le code de KDE. Jamais un #ifdef n'est sur une architecture, seulement sur un OS.

Logram étant une distrib GNU/Linux, les #ifdef sont bons :) .

Pour les paquets qui sont vraiment dépendants d'une architecture, soit on cherche un hack, soit on utilise la bonne vieille méthode.

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).