Et le type qui telecharge beaucoup et qui ecoute tout les morceaux qu'il telecharge ?
On doit pas avoir la même définition de "beaucoup", alors. Parce que les gros téléchargeurs que je connais, même en passant 24h par jour à écouter le "fruit de leur labeur" et avec beaucoup de méthode, je doute qu'ils arrivent à tout écouter. Même à tout entendre, en fait.
Sous Konqueror, ça ne marche pas: la barre est tout le temps visible, et le passage de la souris par-dessus la rend légèrement plus petite (une poignée de pixels de moins en hauteur).
Les trois premiers mois seulement, sauf changement récent. Nerim est au même prix que Free pour du degroupé (même si le service proposé n'est pas le même, je te l'accorde).
Il fonctionne, mais j'ai pas encore réussi à le faire fonctionner. Mais ça viendra...
Pour le transfert Nokia/PC, ça devrait se faire sans problème via Gnokii, mais il reste de toutes manières la bonne vieille technique du "apache+wap". ;)
C'est pas tout à fait la même chose non plus. NWN est certes bien sympathique, mais il est plus à rapprocher d'un Diablo (un diablo intelligent, mais quand même) que d'UO. Il manque toute la partie "artisanat/économie" à NWN pour pouvoir espérer une comparaison.
Et puis la beauté d'un jeu, c'est surtout important quand le reste est creux et sans intérêt :]
Oui, sous Windows il y a plein de choses, je suis bien d'accord. J'ai même une vieille licence Cakewalk qui devrait me permettre de faire ça. Seul hic, je suis sous Linux, et j'ai bien l'intention d'y rester.
Je dois rater quelque-chose, mais dès le début de la partie, mes joueurs se retrouvent au dessus de ... rien, et meurent bêtement. Quel que soit le terrain sélectionné.
En ce qui me concerne, les vaches sont loin d'être maigres. Ou alors c'est les chinois du FBI qui me trafiquent ma balance pour me miner le moral :(
Cela dit, avant de faire une dépèche, j'aimerais arriver à tester l'engin. Si je m'en sors pas avec la version CVS, j'attendrais la sortie "officielle" de la prochaine version (d'ici pas tard, en théorie) pour faire une dépèche un peu plus étoffée.
Sur un linux récent (2.6, idéalement), regarde du coté de /dev/input/, il devrait y avoir (selon les options de compilation du noyau) un fichier "event" regroupant tous les évènements de tous les périphériques gérés par la couche d'input du noyau. Je ne connais pas le (les?) protocoles utilisés, mais ça doit se trouver.
Par ailleurs, pour que ça fonctionne il faut également que X utilise la-dite couche d'input du noyau, et non un /dev/psaux classique, si je ne m'abuse.
Bref, pour faire quelque chose qui marche à la fois sous X et en console et de manière portable, bon courage. Par contre, pour du X "pur", c'est relativement aisé, il y avait même un programme qui faisait quelque-chose de similaire (plus prise de controle d'une souris distante, etc.)
Sauf bourde de ma part, il s'agit en fait de la version 38 de Scorched 3D.
Cela dit, il n'en reste pas moins qu'il s'agit d'un incontournable des jeux libres, si l'on excepte les quelques soucis de compilation (si quelqu'un se sent de faire un ebuild à jour, je suis preneur, j'ai abandonné quand j'ai vu que j'arrivais même pas à le compiler à la main).
Ce qui est un peu dommage, c'est qu'il concerne des points super académiques (théorie des graphes, nom des algorithmes...), alors qu'apparemment, la finale est plutôt jugée sur la "débrouille" (il faut être plus efficace que les autres)
La débrouille, ça consiste aussi à savoir chercher sur google les réponses qui nous manquent.
Bon cela dit, j'ai pas eu le courage de lire le sujet de cette année, mais en général c'est trouvable assez rapidement.
Puisque tu parles du débit intéressant de l'USB2, je suppose que tes périphériques utilisent le module ehci_hcd (ou son équivalent dans le noyal), qui est justement responsable de la gestion de l'USB2. Or il se trouve que j'ai eu (j'ai toujours) de nombreux problèmes avec ce module sur un 2.6.9 (périphérique qui timeout au démarrage, notamment). Je passe outre en désactivant le-dit EHCI (soit en virant le module, soit en recompilant le noyau sans), ce qui nous ramène à un "bête" UHCI ou OHCI (controlleurs USB1), qui eux marchent sans problème.
Alors effectivement, c'est moins rapide, mais au moins ça marche ;)
Donc cracher sur wanadoo, si tu le veux mais quoiqu'on en dise, cote fiabilite et disponibilite, ce sont les meilleurs.
Qu'ils soient meilleurs que free, je veux bien. Mais faut pas pousser mémé dans les orties non plus: comparés à un Nerim (par exemple), ils sont complètement à la ramasse. Même si c'est moins grave que ça n'a été, ça reste encore assez loin de ce qu'on peut appeller un service professionel.
Le monsieur doit être (ou avoir été) BSDiste. Les "slices" sont, si je ne dis pas de conneries, l'équivalent - dans une partition BSD - des partitions logiques à la DOS.
Désolée si j'ai laissé entandre que je trouvais les autotools inutiles.
Pas de problème, d'autant que fondamentalement les autotools peuvent être inutiles (notamment si ton projet est limité à quelques fichiers source et à un nombre restreint d'utilisateurs).
mais je me demande très serieusement: Qu'est ce que les autotools peivent m'apporter que mon simple Makefile ne peux pas faire ?
Plein de choses, cf. ce qu'on dit depuis ton article initial. Plein de choses qui ne te sont pas forcément utiles à toi là tout de suite maintenant, mais plein de choses utiles à beaucoup de développeurs (la majorité, en fait).
A commencer par toute la phase de "configuration", que ta cible configure ne fait qu'approcher.
Sachant que je ne toens pas a passer 3 mois a apprendre les autotools et à configurer mon projet.
Il est clair que passer trois mois sur le sujet ne serait pas raisonnable.
peut être que ca ne compile pas partout, ca navertit pas des dépendances comme le ./configure ou ca re recrée pas la fonction malloc() mais au moins, c'est plus facile à gérer.
Tu vois que tu as une petite idée quand même des avantages des autotools ;)
Mais bon, ce n'est pas tellement "plus facile" que ça à gérer, puisque ça pose problème à ton Anjuta.
Comme je l'ai dit plus bas, je compte sur gcc pour avertir si une lib n'est pas présente, et je trouve ca personellement plus pratique.
Pour toi, oui. Pour tes utilisateurs potentiels, c'est beaucoup moins pratique (ils ne sont pas forcément sensés savoir quelles bibliothèques tu utilise).
Ensuite, je me demande pourquoi:
- on ne ferait pas "make configure" à la place de "./configure"
Parce que ce n'est pas le boulot de make. Le boulot de make, c'est de compiler un programme en s'assurant que seul ce qui est nécessaire sera compilé. Comme je te l'ai expliqué quelques messages plus haut, le configure a un but beaucoup large que ce que fait ton make configure. Ton make configure serait bien embêté s'il devait faire le boulot du configure. (je te laisse réflechir à un Makefile qui aurait pour tâche de générer les Makefiles de ton projet. Ca se fait, mais c'est pas franchement recommandable).
- "./configure" ne nous dit pas ce qui manque
Alors là, je proteste violemment. Je teste sur le premier truc qui me passe sous la main (une applet Gnome, sachant que je n'ai pas les librairies qui vont bien sur ma machine) et:
configure: error: Library requirements (libgnomeui-2.0 >= 2.0.0
libgnome-2.0 >= 2.0.0
gtk+-2.0 >= 2.4.0
libglade-2.0 >= 2.0.0
gconf-2.0 >= 1.1.11) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them.
Je sais pas ce qu'il te faut de plus :)
- ne pas fusionner les fichiers de configurations. Ou les ranger dans un répertoire ".autotools" dans chaque dossier.
On ne fusionne pas les fichiers de configuration justement parce que le but c'est de faire simple. On pourrait probablement décider de remplacer tous les fichiers d'autoconf et automake par un gros machin binaire illisible, mais ça n'est pas le but. De même qu'on pourrait décider de mettre tout le source dans un seul fichier, pour éviter de faire du bazar dans /src. Pourtant, étrangement, les gens semblent chercher à faire l'inverse. Maintenabilité, tout ça...
En outre, le fait d'avoir les répertoires "pointés" cachés, ce n'est qu'une convention unixienne qui n'est pas présente sur toutes les archis couvertes par les autotools, si je ne dis pas de conneries.
PS: la première version de ce post a été perdur pour cause de plantage.
1- Pour les dépendances, de toute facon gcc retournera une erreur compréhensible si la bibliothèque n'existe pas donc ...
Ok. Soit l'erreur (réelle) suivante:
postproc/libswscale.a(rgb2rgb.o)(.text+0x62b9): In function `rgb24toyv12':
: undefined reference to `w1111'
Tu me suggères quoi comme librairie à installer?
Bon ok, j'avoue, j'ai triché. Il s'agit en fait d'un programme autotoolifié (MPlayer 0.93 patché de partout pour des besoins divers). N'empêche que l'erreur de gcc est totalement insuffisante pour déterminer le soft à installer. Surtout avec un nom de symbole manquant aussi peu parlant.
Plus facile que le ./configure ou on voit des centaines de lignes défiler avec un yes ou un no. Lorsque ca ne marche pas, on installe ce qui est marqué sur les lignes avec no en espérant que ca marchera ...
Faudrait voir à apprendre à se servir de configure avant de décréter qu'il ne sert à rien. Un configure bien fait (ceux d'autoconf en particulier) s'arrête lorsqu'il tombe sur une dépendance manquante critique, et il te le signale bien violemment. Aller te taper la liste des yes/no pour savoir ce qui a bien pu merder, c'est un petit peu vain: si ta compilation foire malgré un configure qui termine avec succès, c'est que l'auteur du programme a raté quelque-chose, pas qu'il manque un truc à ton système.
2- Tu peux compiler dans un répertoire séparé:
gcc src/source.c -o dist/source
Le but de ce genre de manipulation étant quand même de permettre à l'utilisateur de compiler son source dans le répertoire de son choix (typiquement s'il n'a pas les droits en écriture sur les sources). Par exemple:
cd ~/src/killerprogram/
/mnt/cdrom/src/killerprogram-0.1/configure
make
Au terme de cette configuration/compilation, rien n'aura été écrit dans le répertoires des sources, et le répertoire de compilation est donc autonome. Tes makefiles sont loin de permettre ce genre de choses facilement.
3- La cible install est très facile à faire. Il sagit juste de copier des fichiers
Eventuellement il faut déterminer l'endroit ou les copier, mettre à jour un uninstall.sh, etc...
je ne pense pas que je réécrirais les autotools, trop compliqué a mon goût. Je trouve que gérer un Makefile est plus simple que gérer les autotools.
C'est évident, et personne ne remet ça en cause. Ce qu'on dit, simplement, c'est qu'un Makefile ne peut pas être comparé à un couple configure/makefile comme tu le fais, et qu'autotools est une aide formidable pour gérer le couple configure/makefile.
De plus je ne fais pas bien confiance aux outils pour déterminer tout seul les dépendances de mon code.
Et tu fais confiance au compilateur pour écrire ton binaire? Tu es vraiment pas méfiant ;)
Sarcasme mis à part, si tu ne fais pas confiance aux autotools pour gérer configure/makefile, j'ai du mal à concevoir que tu puisse faire confiance à Anjuta pour gérer ton projet.
M'enfin ce que j'en dis...
D'autant qu'il y a une grande partie du code que je ne maitrise pas.
Raison de plus pour faire confiance aux outils, alors, BdM! :)
Non, je ne me fiche pas du tout de ce qui se passe à la racine de mon projet ... Je tiens a avoir une arborescence qui se tient. Si ce n'était que moi, je ne mettrais même pas les sources dans src. Il me parait évident que le dosier de projet contient des sources C. Pas besoin de les séparer (à part pour les préserver de la polution autotools).
Et justement, avoir les sources dans un sous-répertoire, ça se tient tout à fait. Ca permet notamment de ne pas mettre /doc, /data et autres données diverses dans des sous-répertoires des sources (ce qui n'est pas excessivement logique, tu en conviendras). Parce que bon, mettre sur un pied d'égalité /libmyengine et /libmyparser sur un pied d'égalité avec /images et /tools, c'est assez discutable.
Sans même parler du cas ou ton projet est multilangage (python, pyrex et C, par exemple) et ou il devient vital de séparer nettement les différents types de sources.
Ensuite, je remarque que ca ne fonctionne pas très bien. Avec Anjuta, et un nouveau projet, pas moyen de compiler un simple HelloWorld.
Comme je l'ai déjà dit, je n'y connais pas grand chose à Anjuta, donc je ne peux pas tellement t'aider. Mais si c'est réellement lui qui prétend gérer les autotools et le le fait pas, il serait plus logique de s'en prendre à lui, plutôt qu'à ces derniers.
Maintenant, si en connaissance de cause tu trouves les autoconf et automake lourdingues, c'est un choix qui se respecte, et libre à toi de faire le script configure qui va bien à la main. Mais si ce qui te pose problème est que, justement, tu ne connais pas ces outils, il est un peu rapide de conclure qu'ils ne servent à rien.
Si je dois les utiliser j'aimmerais bien avoir une doc qui me dise exavtement à quoi cela sert en détail.
Les autotools servent à simplifier l'écriture et la gestion des scripts configure et Makefile. J'ai expliqué plus haut l'utilité des scripts configure. Maintenant pour qu'ils soient réellement utiles, il faut qu'ils ne se limitent pas à se plaindre en cas de problème: par exemple, s'il manque une fonction simple qui existe sur l'immense majorité des plateformes, le configure a pour charge de l'implémenter vite fait dans le projet. Ainsi, si il manque une version de malloc qui initialise le bloc alloué à zéro, il est tout à fait envisageable de rajouter la-dite fonction dans un fichier C à part, fichier qui sera compilé et linké avec le reste du projet.
Dans le cas où la fonction n'est pas facilement rajoutable, ou que le test concerné vise une fonctionnalités spéciale de la plateforme (présence de /dev/urandom, de /proc ou que sais-je), il est important que le configure informe le reste du projet de la non-existence en question. Pour cela, quoi de plus simple qu'un #define? On rajoute donc une floppée de #define PENTIUM_BUG, #define NO_DEV_RANDOM et autres dans un header à part: par exemple config.h.
Reste au final à expliquer à tes Fairefichier (qui ne sont pas forcément au courant) qu'ils doivent linker contre telle ou telle librairie plutôt qu'une autre. Pour ce faire, il faut donc que le script configure soit capable de modifier tes Makefiles (ou du moins un fichier inclus par tes Makefiles, dans le cas où le make local le permet).
En bref, une véritable usine à gaz est nécessaire pour parvenir à un résultat acceptable. Car, comme tu t'en doute, les tests de ton configure (en shell, donc) utilisent souvent des programmes qui ne fonctionnent pas partout pareil (versions différentes de test, de bc, de sed, de grep, ...).
Si on était tordu, on créerait un premier script d'audit, preconfigure par exemple, testerait les commandes shell disponibles et qui construirait un configure fonctionnel sur la plateforme courante. Le configure créerait ensuite le config.h et les Makefile.inc qui vont bien. Simple non? ;)
Pour pallier à ce douloureux problème, on ajoute une contrainte supplémentaire au système: un moteur de macros à part, qui permet d'exprimer les tests du configure de manière portable, sous réserve que le moteur soit disponible. L'interpréteur de macro choisi, c'est m4. Ainsi, au lieu de devoir dépendre de l'existence d'une multitude de commandes shell d'origine diverses, on n'a plus à dépendre que d'un seul outil/langage, simple et portable.
On pourrait donc se débrouiller uniquement avec m4, et écrire nos configure entièrement à la main. Seulement, les autotools nous apportent une aide supplémentaire: ils nous fournissent une floppée de tests (macros) m4 tous faits, pour répondre aux questions les plus courantes Ainsi, on peut savoir simplement si printf fonctionne comme prévu, quel est nom du compilateur (cc, gcc, icc, ...), quel flag est nécessaire pour la production de librairies dynamiques (.so) et quelle est l'extension des executables. Ce genre de choses.
Pourquoi avoir choisi cette solution plutot qu'une autre ?
Ca dépend de l'autre solution que tu proposes. Les choix qui font des autotools ce qu'ils sont viennent des possibilités de l'époque. Il fallait quelquechose qui soit capable de répondre "tout seul" aux cas simples, mais qui puisse être étendu aux cas compliqués.
On peut faire de nombreux reproches aux autotools (et les gens concernés ne s'en privent pas, tu peux en être assuré). Par exemple le bordel qui suit les gros changements de versions d'autoconf/automake. Mais c'est la seule solution raisonnable à l'heure actuelle: les autres sont soit trop lourdes, soit présentes par défaut sur trop peu de plateformes, soit les deux (exemple: Ant, Jam, ...).
En outre, les solutions alternatives ont comme particularité de remplacer le couple configure/makefile, ce qui perturbe les habitués de make.
Qu'est ce qu'est une macro ?
Je devrais t'avoir un peu éclairci à ce sujet, j'espère.
Tes raisons de te passer des autotools sont certainement excellentes, mais je me permet de préciser que, contrairement à ce que tu sembles affirmer, le but du configure n'est pas (pas uniquement, en tous cas) de déterminer les choix de l'utilisateur en matière de configuration de la compilation.
En fait, cet aspect des choses n'est qu'un petit plus "pratique" qui est rendu possible par les scripts de configuration. Le but initial, c'est de déterminer la configuration de la machine de manière automatique. Il suffit de zieuter l'éxecution d'un script configure d'autotools pour voir qu'il ne se limite pas vraiment à prendre en compte les --with-killer-but-nevertheless-unstable-feature qui trainent sur sa ligne de commande. Il teste aussi et surtout l'existence et/ou les prototypes de nombreuses fonctions (plus ou moins) standard. Ainsi, on peut s'assurer que le programme pourra tourner y compris sur des archis différentes (lire éventuellement "merdique").
Alors effectivement, si ton programme est dédié à un ensemble relativement limité d'architectures (genre uniquement des linux de versions récentes), tu peux te permettre de faire ce genre de choses, et effectivement tu n'auras pas besoin d'un Makefile plus compliqué. Au pire, tu auras à demander à l'utilisateur le racine de X et deux-choses un peu siouxes.
Si tu commences à cibler des plateformes plus variées, telles de vieilles versions de divers unices, des unices propriétaires et peu respectueux des standards (j'ai pas dit HPUX! me regardez pas comme ça!), voire des pas-unix-du-tout (mingw, ou dans une moindre mesure cygwin ou beos), tu risques fort de trouver ton makefile "pas compliqué" nettement plus tordu et difficile à maintenir. Tu commenceras à avoir des choses comme:
void main {};
EOF
gcc test.c
if $COMPILATION_FOIRED then echo "Error: you need to install libdeluge-devel to compile my happy program, please come back later.
Rajoute ce genre de choses pour 25 librairies et fonctions tordues. A ce moment-là, tu en viendras peut-être à te dire que les autotools, pour compliqués et contraignant qu'ils soient, pourraient bien te simplifier la vie en fin de compte.
Bien entendu, je suis complètement off-topic et je ne t'aide absolument pas, mais je ne pouvais pas laisser passer l'idée que les autotools ne servent à rien. Qu'ils soient lourds, imparfaits, j'adhère complètement. Mais leur objectif est louable, et relativement bien rempli.
En fait, j'utilise directement un ebuild (script de compil' Gentoo, au cas où) fait pour [1], mais si tu es sous Debian ça ne va pas t'aider des masses. Cependant, tu peux toujours aller lire le-dit ebuild pour voir ce qu'il récupère comme archives et comme patchs.
J'avais trouvé ça, ainsi que d'autres infos utiles, en fouillant un thread[2] de ViaArena. Au pire, on sera sauvés le jour où il existera un noyau "standard" supportant le DRM via (ça pourrait se faire sur le 2.6.10, avec un peu de chance) et une version de Xorg supportant le reste (ça pourrait bien être la suivante aussi).
En tous cas, bon courage, je me sens moins seul d'un coup :p
Je suis approximativement dans le même cas que toi (Acer Aspire 135x, 3D qui ne marche pas). Tu utilises quoi comme distro?
Dernièrement, je suis arrivé à des résultats presques satisfaisants avec XOrg 6.8 patché Unichrome (il y a un ebuild gentoo officieux qui traine, xorg-unichrome-r27, il faut le modifier un peu à la main mais ça passe). En plus, je dois rajouter le module noyau pour le DRM, que j'obtiens à partir du CVS du projet DRI. Je compile ça pour mon noyau (2.6.9), et j'ai un GLX direct acceleré...en root seulement. Avec un utilisateur classique, ca freeze (et necessite un reboot) sans aucune trace dans les logs.
[^] # Re: Commentaires.
Posté par Larry Cow . En réponse au journal Mon avis sur le P2P. Évalué à 3.
On doit pas avoir la même définition de "beaucoup", alors. Parce que les gros téléchargeurs que je connais, même en passant 24h par jour à écouter le "fruit de leur labeur" et avec beaucoup de méthode, je doute qu'ils arrivent à tout écouter. Même à tout entendre, en fait.
[^] # Re: et la toolbar ?
Posté par Larry Cow . En réponse au journal Je crois que ça va couper :p. Évalué à 3.
[^] # Re: oui mais
Posté par Larry Cow . En réponse au journal La FreeBox, ça roxor un max !. Évalué à 2.
[^] # Re: C'est quoi ton portable ?
Posté par Larry Cow . En réponse au journal Formats MIDI. Évalué à 2.
Pour le transfert Nokia/PC, ça devrait se faire sans problème via Gnokii, mais il reste de toutes manières la bonne vieille technique du "apache+wap". ;)
[^] # Re: Notons que ...
Posté par Larry Cow . En réponse au journal Ultima Iris. Évalué à 3.
Et puis la beauté d'un jeu, c'est surtout important quand le reste est creux et sans intérêt :]
[^] # Re: C'est quoi ton portable ?
Posté par Larry Cow . En réponse au journal Formats MIDI. Évalué à 3.
[^] # Re: Hum...
Posté par Larry Cow . En réponse à la dépêche L'équipe de Wormux est fière de vous annoncer la version 0.5.0 !. Évalué à 2.
Par contre, ça peut être une bonne idée de supprimer l'option, si elle est reconnue comme étant non-fonctionnelle et obsolète...
# Hum...
Posté par Larry Cow . En réponse à la dépêche L'équipe de Wormux est fière de vous annoncer la version 0.5.0 !. Évalué à 2.
C'est normal, docteur?
[^] # Re: Windows humilié, mais Windows libéré !
Posté par Larry Cow . En réponse au journal journal inutile (mérite d'être clair). Évalué à 2.
Ah, ce cher Jean-Paul ;)
[^] # Re: C'est quoi ton portable ?
Posté par Larry Cow . En réponse au journal Formats MIDI. Évalué à 2.
[^] # Re: dépêche ?
Posté par Larry Cow . En réponse au journal Ultima Iris. Évalué à 7.
Cela dit, avant de faire une dépèche, j'aimerais arriver à tester l'engin. Si je m'en sors pas avec la version CVS, j'attendrais la sortie "officielle" de la prochaine version (d'ici pas tard, en théorie) pour faire une dépèche un peu plus étoffée.
# Input event
Posté par Larry Cow . En réponse au message accès aux périphériques clavier et souris. Évalué à 2.
Par ailleurs, pour que ça fonctionne il faut également que X utilise la-dite couche d'input du noyau, et non un /dev/psaux classique, si je ne m'abuse.
Bref, pour faire quelque chose qui marche à la fois sous X et en console et de manière portable, bon courage. Par contre, pour du X "pur", c'est relativement aisé, il y avait même un programme qui faisait quelque-chose de similaire (plus prise de controle d'une souris distante, etc.)
# IP over Time?
Posté par Larry Cow . En réponse au journal Jeuxlibres.net : Battle for wesnoth 0.8.8, Scorched 3D v48, et des nouveaux logos. Évalué à 2.
Cela dit, il n'en reste pas moins qu'il s'agit d'un incontournable des jeux libres, si l'on excepte les quelques soucis de compilation (si quelqu'un se sent de faire un ebuild à jour, je suis preneur, j'ai abandonné quand j'ai vu que j'arrivais même pas à le compiler à la main).
[^] # Re: Balèse?
Posté par Larry Cow . En réponse à la dépêche Prologin Edition 2005. Évalué à 2.
La débrouille, ça consiste aussi à savoir chercher sur google les réponses qui nous manquent.
Bon cela dit, j'ai pas eu le courage de lire le sujet de cette année, mais en général c'est trouvable assez rapidement.
# USB1
Posté par Larry Cow . En réponse au message Les périphériques USB-Mass Storage plantent lamentablement. Évalué à 2.
Alors effectivement, c'est moins rapide, mais au moins ça marche ;)
[^] # Re: oui mais
Posté par Larry Cow . En réponse au journal La FreeBox, ça roxor un max !. Évalué à 7.
Qu'ils soient meilleurs que free, je veux bien. Mais faut pas pousser mémé dans les orties non plus: comparés à un Nerim (par exemple), ils sont complètement à la ramasse. Même si c'est moins grave que ça n'a été, ça reste encore assez loin de ce qu'on peut appeller un service professionel.
[^] # Re: slice?
Posté par Larry Cow . En réponse au message Attribuer un espace maximum a un repertoire. Évalué à 3.
[^] # Re: Mouais
Posté par Larry Cow . En réponse au message Utiliser Anjuta sans les autotools. Évalué à 2.
Sinon on peut aussi faire un gcc *.c, hein ;)
[^] # Re: Pinaillage
Posté par Larry Cow . En réponse au message Utiliser Anjuta sans les autotools. Évalué à 2.
Pas de problème, d'autant que fondamentalement les autotools peuvent être inutiles (notamment si ton projet est limité à quelques fichiers source et à un nombre restreint d'utilisateurs).
mais je me demande très serieusement: Qu'est ce que les autotools peivent m'apporter que mon simple Makefile ne peux pas faire ?
Plein de choses, cf. ce qu'on dit depuis ton article initial. Plein de choses qui ne te sont pas forcément utiles à toi là tout de suite maintenant, mais plein de choses utiles à beaucoup de développeurs (la majorité, en fait).
A commencer par toute la phase de "configuration", que ta cible configure ne fait qu'approcher.
Sachant que je ne toens pas a passer 3 mois a apprendre les autotools et à configurer mon projet.
Il est clair que passer trois mois sur le sujet ne serait pas raisonnable.
peut être que ca ne compile pas partout, ca navertit pas des dépendances comme le ./configure ou ca re recrée pas la fonction malloc() mais au moins, c'est plus facile à gérer.
Tu vois que tu as une petite idée quand même des avantages des autotools ;)
Mais bon, ce n'est pas tellement "plus facile" que ça à gérer, puisque ça pose problème à ton Anjuta.
Comme je l'ai dit plus bas, je compte sur gcc pour avertir si une lib n'est pas présente, et je trouve ca personellement plus pratique.
Pour toi, oui. Pour tes utilisateurs potentiels, c'est beaucoup moins pratique (ils ne sont pas forcément sensés savoir quelles bibliothèques tu utilise).
Ensuite, je me demande pourquoi:
- on ne ferait pas "make configure" à la place de "./configure"
Parce que ce n'est pas le boulot de make. Le boulot de make, c'est de compiler un programme en s'assurant que seul ce qui est nécessaire sera compilé. Comme je te l'ai expliqué quelques messages plus haut, le configure a un but beaucoup large que ce que fait ton make configure. Ton make configure serait bien embêté s'il devait faire le boulot du configure. (je te laisse réflechir à un Makefile qui aurait pour tâche de générer les Makefiles de ton projet. Ca se fait, mais c'est pas franchement recommandable).
- "./configure" ne nous dit pas ce qui manque
Alors là, je proteste violemment. Je teste sur le premier truc qui me passe sous la main (une applet Gnome, sachant que je n'ai pas les librairies qui vont bien sur ma machine) et:
Je sais pas ce qu'il te faut de plus :)
- ne pas fusionner les fichiers de configurations. Ou les ranger dans un répertoire ".autotools" dans chaque dossier.
On ne fusionne pas les fichiers de configuration justement parce que le but c'est de faire simple. On pourrait probablement décider de remplacer tous les fichiers d'autoconf et automake par un gros machin binaire illisible, mais ça n'est pas le but. De même qu'on pourrait décider de mettre tout le source dans un seul fichier, pour éviter de faire du bazar dans /src. Pourtant, étrangement, les gens semblent chercher à faire l'inverse. Maintenabilité, tout ça...
En outre, le fait d'avoir les répertoires "pointés" cachés, ce n'est qu'une convention unixienne qui n'est pas présente sur toutes les archis couvertes par les autotools, si je ne dis pas de conneries.
PS: la première version de ce post a été perdur pour cause de plantage.
C'est la saison \o/
[^] # Re: Mouais
Posté par Larry Cow . En réponse au message Utiliser Anjuta sans les autotools. Évalué à 3.
Ok. Soit l'erreur (réelle) suivante:
postproc/libswscale.a(rgb2rgb.o)(.text+0x62b9): In function `rgb24toyv12':
: undefined reference to `w1111'
Tu me suggères quoi comme librairie à installer?
Bon ok, j'avoue, j'ai triché. Il s'agit en fait d'un programme autotoolifié (MPlayer 0.93 patché de partout pour des besoins divers). N'empêche que l'erreur de gcc est totalement insuffisante pour déterminer le soft à installer. Surtout avec un nom de symbole manquant aussi peu parlant.
Plus facile que le ./configure ou on voit des centaines de lignes défiler avec un yes ou un no. Lorsque ca ne marche pas, on installe ce qui est marqué sur les lignes avec no en espérant que ca marchera ...
Faudrait voir à apprendre à se servir de configure avant de décréter qu'il ne sert à rien. Un configure bien fait (ceux d'autoconf en particulier) s'arrête lorsqu'il tombe sur une dépendance manquante critique, et il te le signale bien violemment. Aller te taper la liste des yes/no pour savoir ce qui a bien pu merder, c'est un petit peu vain: si ta compilation foire malgré un configure qui termine avec succès, c'est que l'auteur du programme a raté quelque-chose, pas qu'il manque un truc à ton système.
2- Tu peux compiler dans un répertoire séparé:
gcc src/source.c -o dist/source
Le but de ce genre de manipulation étant quand même de permettre à l'utilisateur de compiler son source dans le répertoire de son choix (typiquement s'il n'a pas les droits en écriture sur les sources). Par exemple:
cd ~/src/killerprogram/
/mnt/cdrom/src/killerprogram-0.1/configure
make
Au terme de cette configuration/compilation, rien n'aura été écrit dans le répertoires des sources, et le répertoire de compilation est donc autonome. Tes makefiles sont loin de permettre ce genre de choses facilement.
3- La cible install est très facile à faire. Il sagit juste de copier des fichiers
Eventuellement il faut déterminer l'endroit ou les copier, mettre à jour un uninstall.sh, etc...
je ne pense pas que je réécrirais les autotools, trop compliqué a mon goût. Je trouve que gérer un Makefile est plus simple que gérer les autotools.
C'est évident, et personne ne remet ça en cause. Ce qu'on dit, simplement, c'est qu'un Makefile ne peut pas être comparé à un couple configure/makefile comme tu le fais, et qu'autotools est une aide formidable pour gérer le couple configure/makefile.
De plus je ne fais pas bien confiance aux outils pour déterminer tout seul les dépendances de mon code.
Et tu fais confiance au compilateur pour écrire ton binaire? Tu es vraiment pas méfiant ;)
Sarcasme mis à part, si tu ne fais pas confiance aux autotools pour gérer configure/makefile, j'ai du mal à concevoir que tu puisse faire confiance à Anjuta pour gérer ton projet.
M'enfin ce que j'en dis...
D'autant qu'il y a une grande partie du code que je ne maitrise pas.
Raison de plus pour faire confiance aux outils, alors, BdM! :)
[^] # Re: Pinaillage
Posté par Larry Cow . En réponse au message Utiliser Anjuta sans les autotools. Évalué à 3.
Et justement, avoir les sources dans un sous-répertoire, ça se tient tout à fait. Ca permet notamment de ne pas mettre /doc, /data et autres données diverses dans des sous-répertoires des sources (ce qui n'est pas excessivement logique, tu en conviendras). Parce que bon, mettre sur un pied d'égalité /libmyengine et /libmyparser sur un pied d'égalité avec /images et /tools, c'est assez discutable.
Sans même parler du cas ou ton projet est multilangage (python, pyrex et C, par exemple) et ou il devient vital de séparer nettement les différents types de sources.
Ensuite, je remarque que ca ne fonctionne pas très bien. Avec Anjuta, et un nouveau projet, pas moyen de compiler un simple HelloWorld.
Comme je l'ai déjà dit, je n'y connais pas grand chose à Anjuta, donc je ne peux pas tellement t'aider. Mais si c'est réellement lui qui prétend gérer les autotools et le le fait pas, il serait plus logique de s'en prendre à lui, plutôt qu'à ces derniers.
Maintenant, si en connaissance de cause tu trouves les autoconf et automake lourdingues, c'est un choix qui se respecte, et libre à toi de faire le script configure qui va bien à la main. Mais si ce qui te pose problème est que, justement, tu ne connais pas ces outils, il est un peu rapide de conclure qu'ils ne servent à rien.
Si je dois les utiliser j'aimmerais bien avoir une doc qui me dise exavtement à quoi cela sert en détail.
Les autotools servent à simplifier l'écriture et la gestion des scripts configure et Makefile. J'ai expliqué plus haut l'utilité des scripts configure. Maintenant pour qu'ils soient réellement utiles, il faut qu'ils ne se limitent pas à se plaindre en cas de problème: par exemple, s'il manque une fonction simple qui existe sur l'immense majorité des plateformes, le configure a pour charge de l'implémenter vite fait dans le projet. Ainsi, si il manque une version de malloc qui initialise le bloc alloué à zéro, il est tout à fait envisageable de rajouter la-dite fonction dans un fichier C à part, fichier qui sera compilé et linké avec le reste du projet.
Dans le cas où la fonction n'est pas facilement rajoutable, ou que le test concerné vise une fonctionnalités spéciale de la plateforme (présence de /dev/urandom, de /proc ou que sais-je), il est important que le configure informe le reste du projet de la non-existence en question. Pour cela, quoi de plus simple qu'un #define? On rajoute donc une floppée de #define PENTIUM_BUG, #define NO_DEV_RANDOM et autres dans un header à part: par exemple config.h.
Reste au final à expliquer à tes Fairefichier (qui ne sont pas forcément au courant) qu'ils doivent linker contre telle ou telle librairie plutôt qu'une autre. Pour ce faire, il faut donc que le script configure soit capable de modifier tes Makefiles (ou du moins un fichier inclus par tes Makefiles, dans le cas où le make local le permet).
En bref, une véritable usine à gaz est nécessaire pour parvenir à un résultat acceptable. Car, comme tu t'en doute, les tests de ton configure (en shell, donc) utilisent souvent des programmes qui ne fonctionnent pas partout pareil (versions différentes de test, de bc, de sed, de grep, ...).
Si on était tordu, on créerait un premier script d'audit, preconfigure par exemple, testerait les commandes shell disponibles et qui construirait un configure fonctionnel sur la plateforme courante. Le configure créerait ensuite le config.h et les Makefile.inc qui vont bien. Simple non? ;)
Pour pallier à ce douloureux problème, on ajoute une contrainte supplémentaire au système: un moteur de macros à part, qui permet d'exprimer les tests du configure de manière portable, sous réserve que le moteur soit disponible. L'interpréteur de macro choisi, c'est m4. Ainsi, au lieu de devoir dépendre de l'existence d'une multitude de commandes shell d'origine diverses, on n'a plus à dépendre que d'un seul outil/langage, simple et portable.
On pourrait donc se débrouiller uniquement avec m4, et écrire nos configure entièrement à la main. Seulement, les autotools nous apportent une aide supplémentaire: ils nous fournissent une floppée de tests (macros) m4 tous faits, pour répondre aux questions les plus courantes Ainsi, on peut savoir simplement si printf fonctionne comme prévu, quel est nom du compilateur (cc, gcc, icc, ...), quel flag est nécessaire pour la production de librairies dynamiques (.so) et quelle est l'extension des executables. Ce genre de choses.
Pourquoi avoir choisi cette solution plutot qu'une autre ?
Ca dépend de l'autre solution que tu proposes. Les choix qui font des autotools ce qu'ils sont viennent des possibilités de l'époque. Il fallait quelquechose qui soit capable de répondre "tout seul" aux cas simples, mais qui puisse être étendu aux cas compliqués.
On peut faire de nombreux reproches aux autotools (et les gens concernés ne s'en privent pas, tu peux en être assuré). Par exemple le bordel qui suit les gros changements de versions d'autoconf/automake. Mais c'est la seule solution raisonnable à l'heure actuelle: les autres sont soit trop lourdes, soit présentes par défaut sur trop peu de plateformes, soit les deux (exemple: Ant, Jam, ...).
En outre, les solutions alternatives ont comme particularité de remplacer le couple configure/makefile, ce qui perturbe les habitués de make.
Qu'est ce qu'est une macro ?
Je devrais t'avoir un peu éclairci à ce sujet, j'espère.
# Pinaillage
Posté par Larry Cow . En réponse au message Utiliser Anjuta sans les autotools. Évalué à 10.
En fait, cet aspect des choses n'est qu'un petit plus "pratique" qui est rendu possible par les scripts de configuration. Le but initial, c'est de déterminer la configuration de la machine de manière automatique. Il suffit de zieuter l'éxecution d'un script configure d'autotools pour voir qu'il ne se limite pas vraiment à prendre en compte les --with-killer-but-nevertheless-unstable-feature qui trainent sur sa ligne de commande. Il teste aussi et surtout l'existence et/ou les prototypes de nombreuses fonctions (plus ou moins) standard. Ainsi, on peut s'assurer que le programme pourra tourner y compris sur des archis différentes (lire éventuellement "merdique").
Alors effectivement, si ton programme est dédié à un ensemble relativement limité d'architectures (genre uniquement des linux de versions récentes), tu peux te permettre de faire ce genre de choses, et effectivement tu n'auras pas besoin d'un Makefile plus compliqué. Au pire, tu auras à demander à l'utilisateur le racine de X et deux-choses un peu siouxes.
Si tu commences à cibler des plateformes plus variées, telles de vieilles versions de divers unices, des unices propriétaires et peu respectueux des standards (j'ai pas dit HPUX! me regardez pas comme ça!), voire des pas-unix-du-tout (mingw, ou dans une moindre mesure cygwin ou beos), tu risques fort de trouver ton makefile "pas compliqué" nettement plus tordu et difficile à maintenir. Tu commenceras à avoir des choses comme:
cat > test.c << EOF
#include <header-precolombien.h>
void main {};
EOF
gcc test.c
if $COMPILATION_FOIRED then echo "Error: you need to install libdeluge-devel to compile my happy program, please come back later.
Rajoute ce genre de choses pour 25 librairies et fonctions tordues. A ce moment-là, tu en viendras peut-être à te dire que les autotools, pour compliqués et contraignant qu'ils soient, pourraient bien te simplifier la vie en fin de compte.
Bien entendu, je suis complètement off-topic et je ne t'aide absolument pas, mais je ne pouvais pas laisser passer l'idée que les autotools ne servent à rien. Qu'ils soient lourds, imparfaits, j'adhère complètement. Mais leur objectif est louable, et relativement bien rempli.
[^] # Re: Pas mieux :(
Posté par Larry Cow . En réponse au message driver unichrome et accélération 3D. Évalué à 3.
J'avais trouvé ça, ainsi que d'autres infos utiles, en fouillant un thread[2] de ViaArena. Au pire, on sera sauvés le jour où il existera un noyau "standard" supportant le DRM via (ça pourrait se faire sur le 2.6.10, avec un peu de chance) et une version de Xorg supportant le reste (ça pourrait bien être la suivante aussi).
En tous cas, bon courage, je me sens moins seul d'un coup :p
[1] http://www.sokhapkin.com/cle266/xorg-unichrome-6.8.0-r27.ebuild(...)
[2] http://forums.viaarena.com/messageview.cfm?catid=28&threadid=60(...)
# Pas mieux :(
Posté par Larry Cow . En réponse au message driver unichrome et accélération 3D. Évalué à 3.
Dernièrement, je suis arrivé à des résultats presques satisfaisants avec XOrg 6.8 patché Unichrome (il y a un ebuild gentoo officieux qui traine, xorg-unichrome-r27, il faut le modifier un peu à la main mais ça passe). En plus, je dois rajouter le module noyau pour le DRM, que j'obtiens à partir du CVS du projet DRI. Je compile ça pour mon noyau (2.6.9), et j'ai un GLX direct acceleré...en root seulement. Avec un utilisateur classique, ca freeze (et necessite un reboot) sans aucune trace dans les logs.
Si quelqu'un a une idée?
[^] # Re: Quelques questions
Posté par Larry Cow . En réponse à la dépêche Pas de Windows ? Alors pas d'ordinateur !. Évalué à 6.
Cf. la première réaction à l'article:
http://ccomb.free.fr/wiki/wakka.php?wiki=AnnuaireRevendeurs(...)
LinuxFR, c'est pas write-only...