> Mais on va prendre des exemples concrets.
> geom_journal sous FreeBSD:
Certe, mais c'est changé tout les combiens ?
Tous les 3 mois ou tous les ans ?
Es-ce intéressant d'utliser et de développer un compilo "bas de gamme" qui va vite uniquement pour ça ?
De plus ses programmes se compilent vite. Ils sont très petits et même si tu en as une dixaine, c'est l'affaire de 10 minutes (c'est le temps pour la bécane, pour toi ça risque d'être plus long (récupérer les sources, ./configure, installation, etc...)).
C'est quasi sans intérêt. De plus il faut voir la contre partie. Un compilo qui fait moins de vérification que gcc, qui n'est pas cross-plateform, qui n'est pas "renforcé" (controle de débordement), etc, etc...
C'est très bien de faire un "make word" pour voir si tout est cohérent. On peut trouver des bugs etc...
Mais les développeurs qui font ça sont rares. En tout cas, il a autre chose à foutre que ça.
Je dis ça sans le moindre mépris, mais ce n'est pas un boulot de développeur, c'est un boulot de testeur (et j'ai beaucoup fait de tests et j'ai beaucoup de respect pour les testeurs, il faut du talent pour être un bon testeur). Dans le cas de Fedora, il y a des bécanes qui sont affectées à ça avec des procédures automatiques, un scheduler pour plannifier les tests, etc...
Au "petit matin" un mail est envoyé sur la mailing devel et les développeurs regardent ce qui les concernes.
En passant, Fedora utilise moch ce qui permet avec une bécane de compiler un programme pour FC4, FC5, FC6, F7, pour i386 pour amd64, etc.
Tu ne lance pas à moch à chaque fois que tu change une ligne de ton code, mais lorsque tu veux diffuser et t'assurer de la qualité du code (es-ce qu'il compile partout ? sur toute les architectures ? il y a-t-il des fichiers en conflit avec d'autres paquets, etc).
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à -1.
> geom_journal sous FreeBSD:
Certe, mais c'est changé tout les combiens ?
Tous les 3 mois ou tous les ans ?
Es-ce intéressant d'utliser et de développer un compilo "bas de gamme" qui va vite uniquement pour ça ?
De plus ses programmes se compilent vite. Ils sont très petits et même si tu en as une dixaine, c'est l'affaire de 10 minutes (c'est le temps pour la bécane, pour toi ça risque d'être plus long (récupérer les sources, ./configure, installation, etc...)).
C'est quasi sans intérêt. De plus il faut voir la contre partie. Un compilo qui fait moins de vérification que gcc, qui n'est pas cross-plateform, qui n'est pas "renforcé" (controle de débordement), etc, etc...
C'est très bien de faire un "make word" pour voir si tout est cohérent. On peut trouver des bugs etc...
Mais les développeurs qui font ça sont rares. En tout cas, il a autre chose à foutre que ça.
Je dis ça sans le moindre mépris, mais ce n'est pas un boulot de développeur, c'est un boulot de testeur (et j'ai beaucoup fait de tests et j'ai beaucoup de respect pour les testeurs, il faut du talent pour être un bon testeur). Dans le cas de Fedora, il y a des bécanes qui sont affectées à ça avec des procédures automatiques, un scheduler pour plannifier les tests, etc...
Au "petit matin" un mail est envoyé sur la mailing devel et les développeurs regardent ce qui les concernes.
En passant, Fedora utilise moch ce qui permet avec une bécane de compiler un programme pour FC4, FC5, FC6, F7, pour i386 pour amd64, etc.
Tu ne lance pas à moch à chaque fois que tu change une ligne de ton code, mais lorsque tu veux diffuser et t'assurer de la qualité du code (es-ce qu'il compile partout ? sur toute les architectures ? il y a-t-il des fichiers en conflit avec d'autres paquets, etc).