Le C++ a beau être standardisé, bien souvent un code prévu pour tel ou
tel compilateur n'est pas compilable avec d'autres, même avec des
bibliothèques identiques.
Quelques exemples :
- Je dois faire des DLL pour AviSynth (logiciel de traitement de
la vidéo). Je n'ai pas réussi à compiler le code sous autre chose que
Visual C++ : Comeau accepte de le compiler mais refuse de faire une
DLL ; gcc et Borland C++ refusent carrément le code.
- J'ai voulu intégrer une bibliothèque open-source, ffmpeg, dans
mon code. J'ai dû y renoncer, car je programme sous BC++ et le code de
la bibliothèque est en gcc. Du coup, j'ai créé une DLL avec g++, que
j'appelle depuis mon programme compilé sous BC++. (Heureusement que
COM m'y autorise !)
- Le mois dernier, je me suis penché sur le remplacement de
Borland C++. J'ai donc essayé de compiler mon code sous Visual C++ et
Comeau. J'ai fini par y arriver (sauf pour le link -- y'a des
ressources qui merdent, mais c'est hors-sujet ici), mais ce fut un
travail assez fastidieux, et j'aurais vraiment eu du mal si ce n'avait
pas été un code que je connais bien.
(J'avais déjà abandonné la piste g++ car je n'avais pas réussi à
y compiler OWL (bibliothèque GUI) correctement.)
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour
votre code (vérification avec plusieurs compilos différents ?), que
pour les bibliothèques (celles dont le source est fourni bien sûr).
Le C++ a beau être standardisé, bien souvent un code prévu pour tel ou tel compilateur n'est pas compilable avec d'autres, même avec des bibliothèques identiques.
Quelques exemples :
- Je dois faire des DLL pour AviSynth (logiciel de traitement de la vidéo). Je n'ai pas réussi à compiler le code sous autre chose que Visual C++ : Comeau accepte de le compiler mais refuse de faire une DLL ; gcc et Borland C++ refusent carrément le code.
- J'ai voulu intégrer une bibliothèque open-source, ffmpeg, dans mon code. J'ai dû y renoncer, car je programme sous BC++ et le code de la bibliothèque est en gcc. Du coup, j'ai créé une DLL avec g++, que j'appelle depuis mon programme compilé sous BC++. (Heureusement que COM m'y autorise !)
- Le mois dernier, je me suis penché sur le remplacement de Borland C++. J'ai donc essayé de compiler mon code sous Visual C++ et Comeau. J'ai fini par y arriver (sauf pour le link -- y'a des ressources qui merdent, mais c'est hors-sujet ici), mais ce fut un travail assez fastidieux, et j'aurais vraiment eu du mal si ce n'avait pas été un code que je connais bien. (J'avais déjà abandonné la piste g++ car je n'avais pas réussi à y compiler OWL (bibliothèque GUI) correctement.)
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour votre code (vérification avec plusieurs compilos différents ?), que pour les bibliothèques (celles dont le source est fourni bien sûr).
Merci d'avance...
moi naivement je compile (sous g++) avec -ansi -pedantic et je me dis que ça doit quasiment suffir à assurer la compatibilité du code source... Mais ça ne résoud pas le problème de l'utilisation de librairies extérieures. Désolé de ne pas pouvoir t'aider vraiment.
Bâjour,
Le C++ a beau être standardisé, bien souvent un code prévu pour tel ou
tel compilateur n'est pas compilable avec d'autres, même avec des
bibliothèques identiques.
Quelques exemples :
- Je dois faire des DLL pour AviSynth (logiciel de traitement de
la vidéo). Je n'ai pas réussi à compiler le code sous autre chose que
Visual C++ : Comeau accepte de le compiler mais refuse de faire une
DLL ; gcc et Borland C++ refusent carrément le code.
- J'ai voulu intégrer une bibliothèque open-source, ffmpeg, dans
mon code. J'ai dû y renoncer, car je programme sous BC++ et le code de
la bibliothèque est en gcc. Du coup, j'ai créé une DLL avec g++, que
j'appelle depuis mon programme compilé sous BC++. (Heureusement que
COM m'y autorise !)
- Le mois dernier, je me suis penché sur le remplacement de
Borland C++. J'ai donc essayé de compiler mon code sous Visual C++ et
Comeau. J'ai fini par y arriver (sauf pour le link -- y'a des
ressources qui merdent, mais c'est hors-sujet ici), mais ce fut un
travail assez fastidieux, et j'aurais vraiment eu du mal si ce n'avait
pas été un code que je connais bien.
(J'avais déjà abandonné la piste g++ car je n'avais pas réussi à
y compiler OWL (bibliothèque GUI) correctement.)
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour
votre code (vérification avec plusieurs compilos différents ?), que
pour les bibliothèques (celles dont le source est fourni bien sûr).
Merci d'avance...
moi naivement je compile (sous g++) avec -ansi -pedantic et je me dis que ça
doit quasiment suffir à assurer la compatibilité du code source...
Mais ça ne résoud pas le problème de l'utilisation de librairies extérieures.
Désolé de ne pas pouvoir t'aider vraiment.
Le C++ a beau être standardisé, bien souvent un code prévu pour tel ou tel compilateur n'est pas compilable avec d'autres, même avec des bibliothèques identiques.
Quelques exemples :
- Je dois faire des DLL pour AviSynth (logiciel de traitement de la vidéo). Je n'ai pas réussi à compiler le code sous autre chose que Visual C++ : Comeau accepte de le compiler mais refuse de faire une DLL ; gcc et Borland C++ refusent carrément le code.
- J'ai voulu intégrer une bibliothèque open-source, ffmpeg, dans mon code. J'ai dû y renoncer, car je programme sous BC++ et le code de la bibliothèque est en gcc. Du coup, j'ai créé une DLL avec g++, que j'appelle depuis mon programme compilé sous BC++. (Heureusement que COM m'y autorise !)
- Le mois dernier, je me suis penché sur le remplacement de Borland C++. J'ai donc essayé de compiler mon code sous Visual C++ et Comeau. J'ai fini par y arriver (sauf pour le link -- y'a des ressources qui merdent, mais c'est hors-sujet ici), mais ce fut un travail assez fastidieux, et j'aurais vraiment eu du mal si ce n'avait pas été un code que je connais bien. (J'avais déjà abandonné la piste g++ car je n'avais pas réussi à y compiler OWL (bibliothèque GUI) correctement.)
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour votre code (vérification avec plusieurs compilos différents ?), que pour les bibliothèques (celles dont le source est fourni bien sûr).
Merci d'avance...
moi naivement je compile (sous g++) avec -ansi -pedantic et je me dis que ça doit quasiment suffir à assurer la compatibilité du code source... Mais ça ne résoud pas le problème de l'utilisation de librairies extérieures. Désolé de ne pas pouvoir t'aider vraiment.
Jean-Marc Bourguet
Fabien LE LEZ writes:
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour votre code (vérification avec plusieurs compilos différents ?), que pour les bibliothèques (celles dont le source est fourni bien sûr).
Nous avons simplement des builds reguliers (pas toutes les nuits mais quand meme plusieurs fois par semaine) par plateforme (Solaris 32, Solaris 64, HP-UX 32, HP-UX 64, AIX 32, AIX 64, Linux x86, Linux ia64, Linux amd64 et on va peut-etre ajouter Solaris x86, Solarix amd64) Les developpeurs ne verifient que sur la platerforme sur laquelle ils developpent (Solaris 32, Linux x86) et les CM (ceux qui s'occupent du Configuration Management) notifient le dernier a avoir fait un check in d'un fichier des pb de compilation eventuel sur les autres plateformes.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ <gramster@gramster.com> writes:
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour
votre code (vérification avec plusieurs compilos différents ?), que
pour les bibliothèques (celles dont le source est fourni bien sûr).
Nous avons simplement des builds reguliers (pas toutes les nuits mais
quand meme plusieurs fois par semaine) par plateforme (Solaris 32,
Solaris 64, HP-UX 32, HP-UX 64, AIX 32, AIX 64, Linux x86, Linux ia64,
Linux amd64 et on va peut-etre ajouter Solaris x86, Solarix amd64) Les
developpeurs ne verifient que sur la platerforme sur laquelle ils
developpent (Solaris 32, Linux x86) et les CM (ceux qui s'occupent du
Configuration Management) notifient le dernier a avoir fait un check
in d'un fichier des pb de compilation eventuel sur les autres
plateformes.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour votre code (vérification avec plusieurs compilos différents ?), que pour les bibliothèques (celles dont le source est fourni bien sûr).
Nous avons simplement des builds reguliers (pas toutes les nuits mais quand meme plusieurs fois par semaine) par plateforme (Solaris 32, Solaris 64, HP-UX 32, HP-UX 64, AIX 32, AIX 64, Linux x86, Linux ia64, Linux amd64 et on va peut-etre ajouter Solaris x86, Solarix amd64) Les developpeurs ne verifient que sur la platerforme sur laquelle ils developpent (Solaris 32, Linux x86) et les CM (ceux qui s'occupent du Configuration Management) notifient le dernier a avoir fait un check in d'un fichier des pb de compilation eventuel sur les autres plateformes.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Casillux
Jean-Marc Bourguet wrote:
Fabien LE LEZ writes:
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour votre code (vérification avec plusieurs compilos différents ?), que pour les bibliothèques (celles dont le source est fourni bien sûr).
Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).
Jean-Marc Bourguet wrote:
Fabien LE LEZ <gramster@gramster.com> writes:
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour
votre code (vérification avec plusieurs compilos différents ?), que
pour les bibliothèques (celles dont le source est fourni bien sûr).
Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour votre code (vérification avec plusieurs compilos différents ?), que pour les bibliothèques (celles dont le source est fourni bien sûr).
Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).
Fabien LE LEZ
On 26 Oct 2005 16:55:50 +0200, Jean-Marc Bourguet :
Nous avons simplement des builds reguliers [...] par plateforme
Avec des compilateurs différents, ou uniquement gcc ?
On 26 Oct 2005 16:55:50 +0200, Jean-Marc Bourguet <jm@bourguet.org>:
Nous avons simplement des builds reguliers [...] par plateforme
Avec des compilateurs différents, ou uniquement gcc ?
On 26 Oct 2005 16:55:50 +0200, Jean-Marc Bourguet :
Nous avons simplement des builds reguliers [...] par plateforme
Avec des compilateurs différents, ou uniquement gcc ?
Marc Boyer
Casillux a écrit :
Jean-Marc Bourguet wrote:
Fabien LE LEZ writes:
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour votre code (vérification avec plusieurs compilos différents ?), que pour les bibliothèques (celles dont le source est fourni bien sûr).
Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).
Même pour certaines PME, maintenir la douzaine de machine cible n'est pas évident.
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangereux que prendre un boulevard dans le sens légal. À qui la faute ?
Casillux <gellysv@pasdespammerci.yahoo.fr> a écrit :
Jean-Marc Bourguet wrote:
Fabien LE LEZ <gramster@gramster.com> writes:
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour
votre code (vérification avec plusieurs compilos différents ?), que
pour les bibliothèques (celles dont le source est fourni bien sûr).
Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).
Même pour certaines PME, maintenir la douzaine de machine
cible n'est pas évident.
Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangereux
que prendre un boulevard dans le sens légal. À qui la faute ?
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour votre code (vérification avec plusieurs compilos différents ?), que pour les bibliothèques (celles dont le source est fourni bien sûr).
Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).
Même pour certaines PME, maintenir la douzaine de machine cible n'est pas évident.
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangereux que prendre un boulevard dans le sens légal. À qui la faute ?
Fabien LE LEZ
On Wed, 26 Oct 2005 20:23:51 +0200, Casillux :
Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).
Remarque que si effectivement avoir une quinzaine de machines différentes n'est pas à la portée du premier venu, tester le code avec plusieurs compilateurs sur une machine donnée est nettement plus abordable... mais encore faut-il la volonté de faire du code compatible.
On Wed, 26 Oct 2005 20:23:51 +0200, Casillux
<gellysv@pasdespammerci.yahoo.fr>:
Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).
Remarque que si effectivement avoir une quinzaine de machines
différentes n'est pas à la portée du premier venu, tester le code avec
plusieurs compilateurs sur une machine donnée est nettement plus
abordable... mais encore faut-il la volonté de faire du code
compatible.
J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).
Remarque que si effectivement avoir une quinzaine de machines différentes n'est pas à la portée du premier venu, tester le code avec plusieurs compilateurs sur une machine donnée est nettement plus abordable... mais encore faut-il la volonté de faire du code compatible.
Jean-Marc Bourguet
Fabien LE LEZ writes:
On 26 Oct 2005 16:55:50 +0200, Jean-Marc Bourguet :
Nous avons simplement des builds reguliers [...] par plateforme
Avec des compilateurs différents, ou uniquement gcc ?
Avec les compilateurs qu'on utilise sur la plateforme (SparcWorks sur Sun, aCC sur HP-UX, xlC sur IBM, g++ sur Linux) bien qu'il y a eu au moins un projet qui utilisait g++ aussi sur Sun pour le developpement (mais pas pour la release).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ <gramster@gramster.com> writes:
On 26 Oct 2005 16:55:50 +0200, Jean-Marc Bourguet <jm@bourguet.org>:
Nous avons simplement des builds reguliers [...] par plateforme
Avec des compilateurs différents, ou uniquement gcc ?
Avec les compilateurs qu'on utilise sur la plateforme (SparcWorks sur
Sun, aCC sur HP-UX, xlC sur IBM, g++ sur Linux) bien qu'il y a eu au
moins un projet qui utilisait g++ aussi sur Sun pour le developpement
(mais pas pour la release).
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
On 26 Oct 2005 16:55:50 +0200, Jean-Marc Bourguet :
Nous avons simplement des builds reguliers [...] par plateforme
Avec des compilateurs différents, ou uniquement gcc ?
Avec les compilateurs qu'on utilise sur la plateforme (SparcWorks sur Sun, aCC sur HP-UX, xlC sur IBM, g++ sur Linux) bien qu'il y a eu au moins un projet qui utilisait g++ aussi sur Sun pour le developpement (mais pas pour la release).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
Casillux writes:
Jean-Marc Bourguet wrote:
Fabien LE LEZ writes:
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour votre code (vérification avec plusieurs compilos différents ?), que pour les bibliothèques (celles dont le source est fourni bien sûr). Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier:-).
Je pourrais imaginer facilement des choses plus compliquees (compiler sur des plateformes pour lesquelles on ne fait pas de release, compiler avec d'autres compilateurs que ceux qui servent pour les releases, compiler automatiquement avant le checkin dans le systeme de gestion de source sur toutes les plateformes et refuser si ca ne compile pas, utiliser des verificateurs statiques de code, ...)
Avoir des builds reguliers pour toutes les machines dont on dispose ne necessite pas grand chose tant qu'on a un support adequat de l'OS. Le support batch/cron de Unix est minimal -- moins que ca on ne peut pas dire que c'est fourni par l'OS -- et pourtant il suffit.
De toute facon, batir comme ca n'est que la premiere etape, apres il faut executer les tests.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour
votre code (vérification avec plusieurs compilos différents ?), que
pour les bibliothèques (celles dont le source est fourni bien sûr).
Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier:-).
Je pourrais imaginer facilement des choses plus compliquees (compiler
sur des plateformes pour lesquelles on ne fait pas de release,
compiler avec d'autres compilateurs que ceux qui servent pour les
releases, compiler automatiquement avant le checkin dans le systeme de
gestion de source sur toutes les plateformes et refuser si ca ne
compile pas, utiliser des verificateurs statiques de code, ...)
Avoir des builds reguliers pour toutes les machines dont on dispose ne
necessite pas grand chose tant qu'on a un support adequat de l'OS. Le
support batch/cron de Unix est minimal -- moins que ca on ne peut pas
dire que c'est fourni par l'OS -- et pourtant il suffit.
De toute facon, batir comme ca n'est que la premiere etape, apres il
faut executer les tests.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour votre code (vérification avec plusieurs compilos différents ?), que pour les bibliothèques (celles dont le source est fourni bien sûr). Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier:-).
Je pourrais imaginer facilement des choses plus compliquees (compiler sur des plateformes pour lesquelles on ne fait pas de release, compiler avec d'autres compilateurs que ceux qui servent pour les releases, compiler automatiquement avant le checkin dans le systeme de gestion de source sur toutes les plateformes et refuser si ca ne compile pas, utiliser des verificateurs statiques de code, ...)
Avoir des builds reguliers pour toutes les machines dont on dispose ne necessite pas grand chose tant qu'on a un support adequat de l'OS. Le support batch/cron de Unix est minimal -- moins que ca on ne peut pas dire que c'est fourni par l'OS -- et pourtant il suffit.
De toute facon, batir comme ca n'est que la premiere etape, apres il faut executer les tests.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
Marc Boyer writes:
Casillux a écrit :
Jean-Marc Bourguet wrote:
Fabien LE LEZ writes:
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour votre code (vérification avec plusieurs compilos différents ?), que pour les bibliothèques (celles dont le source est fourni bien sûr).
Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).
Même pour certaines PME, maintenir la douzaine de machine cible n'est pas évident.
Pour une PME qui fait du software, ca ne devrait pas poser de probleme. Le mieux est d'avoir quelqu'un qui l'a deja fait, ca evite de tatonner un temps -- mais sinon administrer un parc de machines unix meme heterogene et y mettre en place un environnement de developpement a moitie raisonnable, c'est pas complique (je l'ai fait quand j'etais a la fac en me formant moi-meme la dessus et en ayant d'autres charges en meme temps).
Je fonderais une societe unipersonnelle pour faire du soft, le premier code -- a moins que je trouve quelque chose de tout fait -- que j'ecrirais serait pour mettre ca en place.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Casillux <gellysv@pasdespammerci.yahoo.fr> a écrit :
Jean-Marc Bourguet wrote:
Fabien LE LEZ <gramster@gramster.com> writes:
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour
votre code (vérification avec plusieurs compilos différents ?), que
pour les bibliothèques (celles dont le source est fourni bien sûr).
Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).
Même pour certaines PME, maintenir la douzaine de machine cible
n'est pas évident.
Pour une PME qui fait du software, ca ne devrait pas poser de
probleme. Le mieux est d'avoir quelqu'un qui l'a deja fait, ca evite
de tatonner un temps -- mais sinon administrer un parc de machines
unix meme heterogene et y mettre en place un environnement de
developpement a moitie raisonnable, c'est pas complique (je l'ai fait
quand j'etais a la fac en me formant moi-meme la dessus et en ayant
d'autres charges en meme temps).
Je fonderais une societe unipersonnelle pour faire du soft, le premier
code -- a moins que je trouve quelque chose de tout fait -- que
j'ecrirais serait pour mettre ca en place.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Aussi aimerais-je savoir comment vous gérez ce problème, tant pour votre code (vérification avec plusieurs compilos différents ?), que pour les bibliothèques (celles dont le source est fourni bien sûr).
Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).
Même pour certaines PME, maintenir la douzaine de machine cible n'est pas évident.
Pour une PME qui fait du software, ca ne devrait pas poser de probleme. Le mieux est d'avoir quelqu'un qui l'a deja fait, ca evite de tatonner un temps -- mais sinon administrer un parc de machines unix meme heterogene et y mettre en place un environnement de developpement a moitie raisonnable, c'est pas complique (je l'ai fait quand j'etais a la fac en me formant moi-meme la dessus et en ayant d'autres charges en meme temps).
Je fonderais une societe unipersonnelle pour faire du soft, le premier code -- a moins que je trouve quelque chose de tout fait -- que j'ecrirais serait pour mettre ca en place.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Rémy
"Jean-Marc Bourguet" a écrit dans le message de news:
Marc Boyer writes:
Jean-Marc Bourguet wrote:
Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).
Même pour certaines PME, maintenir la douzaine de machine cible n'est pas évident.
Pour une PME qui fait du software, ca ne devrait pas poser de probleme. Le mieux est d'avoir quelqu'un qui l'a deja fait, ca evite de tatonner un temps -- mais sinon administrer un parc de machines unix meme heterogene et y mettre en place un environnement de developpement a moitie raisonnable, c'est pas complique (je l'ai fait quand j'etais a la fac en me formant moi-meme la dessus et en ayant d'autres charges en meme temps).
Je crois que le problème est beaucoup plus financier.
Achat des machines, contrats de maintenance, achat des licences des compilateurs,...
Rémy
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message de news:
pxb3bmnwi7g.fsf@news.bourguet.org...
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Jean-Marc Bourguet wrote:
Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier
:-).
Même pour certaines PME, maintenir la douzaine de machine cible
n'est pas évident.
Pour une PME qui fait du software, ca ne devrait pas poser de
probleme. Le mieux est d'avoir quelqu'un qui l'a deja fait, ca evite
de tatonner un temps -- mais sinon administrer un parc de machines
unix meme heterogene et y mettre en place un environnement de
developpement a moitie raisonnable, c'est pas complique (je l'ai fait
quand j'etais a la fac en me formant moi-meme la dessus et en ayant
d'autres charges en meme temps).
Je crois que le problème est beaucoup plus financier.
Achat des machines, contrats de maintenance, achat des licences des
compilateurs,...
"Jean-Marc Bourguet" a écrit dans le message de news:
Marc Boyer writes:
Jean-Marc Bourguet wrote:
Nous avons simplement des builds reguliers
J'aime bien le "simplement" tout à fait à la porté d'un particulier :-).
Même pour certaines PME, maintenir la douzaine de machine cible n'est pas évident.
Pour une PME qui fait du software, ca ne devrait pas poser de probleme. Le mieux est d'avoir quelqu'un qui l'a deja fait, ca evite de tatonner un temps -- mais sinon administrer un parc de machines unix meme heterogene et y mettre en place un environnement de developpement a moitie raisonnable, c'est pas complique (je l'ai fait quand j'etais a la fac en me formant moi-meme la dessus et en ayant d'autres charges en meme temps).
Je crois que le problème est beaucoup plus financier.
Achat des machines, contrats de maintenance, achat des licences des compilateurs,...
