>Comme si ça leur était JAMAIS arrivé, une compil qui plante...
mais si ca arrive, quand le source est bourré de fautes, les scripts etc...
> Mais il faut pas le dire, parce que ça serait 1. >avouer qu'ils sont nuls ;
si on a tout fait correctement et que ca marche pas, ben c pas de notre faute, mais de la faute du code source
> 2. dire du mal de Linux.
en effet bien souvent les gens viennent a dire "linux pas convivial gnagnagnaaaaa"
alors qu'ils se plaignent de la COMPILATION (une operation complexe, hein quelque soit le systeme)
d un programme en BETA voir ALPHA (xine franchement... ou du code CVS de aviplay par exemple)
>Non, il est vraiment inconcevable, avec toutes >les avancées faites en étude d'ergonomie, de >passer des jours à installer un programme.
celaa serait inconcevable si on parlait de programes finis et bien stables
comme le sont gimp ou xmms
ou si on parlait des installateurs des distributions ou des RPM
mais la vous tentez de compiler un code vraiment pas stable, un projet qu on vous laisse utiliser mais qui n est pas fini..
imaginez qu'un editeur comme ibm vous laisse compiler en cours de developpement une version d AIX... c pareil
xine j ai abandonné y a quand meme qq temps,
refaire moi meme l'ensemble des patchs, dependances, corrections des scripts, etc.. c t lourd.
sinon en ce qui concerne les maj de distribs, parfois ca aide (librairies à jour, programme pour compiler mis à jour etc... )
le probleme actuel qui merde bien des projets (comme avifile) c est le fait que redhat et d'autres aient mis un gcc 2.96
gcc 2.96, c bien, ce n est pas en soi une erreur
il est plus a jour debuggé etc..
mais justement, bien des gens ont optimisé leurs codes avec des fonctions non documentés voir meme des bugs de 2.95
chose que 2.96 n etait pas tenu de respecter, et que la vraie version prochaine de gcc (la 3.0 ) ne supporte pas non plus.
en particulier certains trucs de fonctions inline que permet gcc 2.95.x mais pas gcc 3.0 , forcement les codes sources qui utilsent ca, ont des problemes (encore une fois avifile , d ou les gens qui doivent editer le code source sur mdk 8.0 )
vouais c ardu et compliqué et tout et tout et tout
mais pour ceux que ca enervent a fond, normalement, l'auteur de avifile devrait penser a eux et leur faire des paquets rpm/deb/tar.gz deja compilé (et testé chez lui) pour passer outre.
vouais normalement.
notez bien que pas mal de programmeurs sous linux le font, pas tous.
[^] # Re: Une autre raison
Posté par Anonyme . En réponse à la dépêche Support des menus dans les DVD. Évalué à 2.
mais si ca arrive, quand le source est bourré de fautes, les scripts etc...
> Mais il faut pas le dire, parce que ça serait 1. >avouer qu'ils sont nuls ;
si on a tout fait correctement et que ca marche pas, ben c pas de notre faute, mais de la faute du code source
> 2. dire du mal de Linux.
en effet bien souvent les gens viennent a dire "linux pas convivial gnagnagnaaaaa"
alors qu'ils se plaignent de la COMPILATION (une operation complexe, hein quelque soit le systeme)
d un programme en BETA voir ALPHA (xine franchement... ou du code CVS de aviplay par exemple)
>Non, il est vraiment inconcevable, avec toutes >les avancées faites en étude d'ergonomie, de >passer des jours à installer un programme.
celaa serait inconcevable si on parlait de programes finis et bien stables
comme le sont gimp ou xmms
ou si on parlait des installateurs des distributions ou des RPM
mais la vous tentez de compiler un code vraiment pas stable, un projet qu on vous laisse utiliser mais qui n est pas fini..
imaginez qu'un editeur comme ibm vous laisse compiler en cours de developpement une version d AIX... c pareil
xine j ai abandonné y a quand meme qq temps,
refaire moi meme l'ensemble des patchs, dependances, corrections des scripts, etc.. c t lourd.
sinon en ce qui concerne les maj de distribs, parfois ca aide (librairies à jour, programme pour compiler mis à jour etc... )
le probleme actuel qui merde bien des projets (comme avifile) c est le fait que redhat et d'autres aient mis un gcc 2.96
gcc 2.96, c bien, ce n est pas en soi une erreur
il est plus a jour debuggé etc..
mais justement, bien des gens ont optimisé leurs codes avec des fonctions non documentés voir meme des bugs de 2.95
chose que 2.96 n etait pas tenu de respecter, et que la vraie version prochaine de gcc (la 3.0 ) ne supporte pas non plus.
en particulier certains trucs de fonctions inline que permet gcc 2.95.x mais pas gcc 3.0 , forcement les codes sources qui utilsent ca, ont des problemes (encore une fois avifile , d ou les gens qui doivent editer le code source sur mdk 8.0 )
vouais c ardu et compliqué et tout et tout et tout
mais pour ceux que ca enervent a fond, normalement, l'auteur de avifile devrait penser a eux et leur faire des paquets rpm/deb/tar.gz deja compilé (et testé chez lui) pour passer outre.
vouais normalement.
notez bien que pas mal de programmeurs sous linux le font, pas tous.