Forums Les Mains dans le Cambouis

News

Articles

Médias

Forums

Tutoriels

Le pub des programmeurs

1 927 réponses
117 participants
131 748 vues
130 followers

Anonyme

521397

Sujet de la discussion Posté le 25/08/2005 à 17:21:03

Salut

y a des programeurs sur AF si oui vous bossez sous quoi ?

Afficher le sujet de la discussion

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

326 Posté le 05/09/2006 à 03:03:28

Perso, j'aime pas cygwin pour compiler, parce que ca prend un temps fou: deja de base, gcc n'est pas super rapide pour compiler, mais surtout, l'emulation au dessus de cygwin est super lourde.

Pour compiler du code "simple" sous windows, pendant un temps, je cross-compilais depuis linux avec mingwin. Maintenant, de temps en temps, pour certains projets, j'utilise scons pour le systeme de build, qui est cense prendre en charge les differences de plateformes automatiquement.

zieQ

466

Posteur·euse AFfamé·e

Membre depuis 22 ans

327 Posté le 05/09/2006 à 09:32:00

A un moment, j'utilisais conjointement mingw et VC (et même cygwin un temps) pour compiler un projet, y a pas photo, VC compilait nettement plus vite. Maintenant faut voir si ton projet est facilement "portable" sur VC, parce que tu risques de perdre pas mal de temps dessus si t'as pas pris les bonnes dispositions dès le départ ;)

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

328 Posté le 05/09/2006 à 09:52:36

Non mais attention, la lenteur cygwin ou mingw provient avant tout de l'emulation de tout ce qu'il y a autour. Sur la meme machine, entre gcc sous linux et gcc mingw sous windows (meme version de gcc, compile a la main), il y a un rapport de 2 a 3 facile pour la vitesse.

Par exemple, tout ce qui est makefile + shell, c'est pas top sous windows, car windows a des processus tres lourds, contrairement aux unix en general, et en particulier linux, ou la creation de processus devient de plus en plus legere. Ensuite, bash sous mingw est extrememement lent, je pense que la moitie du temps au moins passe a la compilation d'un projet sous makefile n'est pas prise par gcc (le fait que windows n'ait pas d'office un environnement shell me depasse: cmd.exe ne supporte meme pas le copier coller, les capacites d'edition de ligne sont catastrophiques, c'est vraiment intolerable pour moi de bosser la dessus... C'est quand meme pas complique d'ecrire un remplacant de cmd.exe, merde.　Meme powershell utilise encore le meme environnement graphique qui est toujours aussi pourri...).

Si tu utilises mingw sous linux, pour faire du cross compiling, tu verras que niveau rapidite de compilation, ca n'a rien a voir. Et apres, tu peux faire tourner sous wine. Ca parait bourrin, mais c'est assez pratique en fait. Le probleme est lorsque tu commences a dependre de pas mal de librairies externes

Nyl auster

3862

Squatteur·euse d’AF

Membre depuis 20 ans

329 Posté le 05/09/2006 à 10:45:22

Bonnjour à tous, j'ai une petite question à vous poser. Je ne suis pas DU TOUT programmeur, mais il m'arrive à l'occasion de bricoler de petits modules très très simples en c++ pour synthEdit (synthétiseur modulaire). J'utilise un IDE se nommant "code::blocks" pour cela. Le connaissez vous et qu'en pensez vous?
En compilant avec ce dernier, certains bugs que j'ai avec dev c++ disparaissent; comment est ce possible puisqu'il s'agit du même "compilateur" si j'ai bien compris?

Mon site

Anonyme

521397

330 Posté le 05/09/2006 à 10:50:55

Citation : Si tu utilises mingw sous linux, pour faire du cross compiling, tu verras que niveau rapidite de compilation, ca n'a rien a voir.

J'ai jamais penser à faire ca, c'est compliqué à mettre en eouvre? mais on peut lié quand meme avec des librairies dynamique? ca doit avoir ses limites non? (je suis très très intéréssé par ca, car je suis jamais arrivé à compiler correctement du code avec cygwin, j'ai tjs des erreurs con que je n'ais pas avec gcc).

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

331 Posté le 05/09/2006 à 11:22:32

Citation :
J'ai jamais penser à faire ca, c'est compliqué à mettre en eouvre? mais on peut lié quand meme avec des librairies dynamique? ca doit avoir ses limites non? (je suis très très intéréssé par ca, car je suis jamais arrivé à compiler correctement du code avec cygwin, j'ai tjs des erreurs con que je n'ais pas avec gcc).

Ca depend de ta distribution. Perso, j'utilise essentiellement debian et ubuntu, qui toutes les deux fournissent le tout package. Compiler soi meme des cross compilateurs est plus difficile (le compilo, ca va, mais la libc, c'est deja plus tordu), par contre, mais ca se fait. Je l'ai fait pour compiler des programmes sur mon routeur qui tourne sous arch MIPS. Apres, c'est sur que si tes projets dependent de 30 librairies que tu vas devoir elles aussi cross compiler, ca va devenir tendu... Je pense qu'une fois que j'aurais un PC avec l'architecture VT, styles les core, j'utiliserais xen pour compiler des projets sous windows depuis linux.

> Wolfen, j'ai enfin reussi a faire marcher le truc sous windows, mais putain que c'est penible... En fait, j'hallucine un peu sur la difficulte de developper sous windows avec des librairies standart comme boost et cie. Ils ont 10 ans de retard :oo:

Sous linux, en 2 commandes, j'ai tous les headers + librairies installees, alors que la, il faut compiler boost, etc...

J'ai mis un zip bordelique avec tous les binaires (ca devrait donc marcher sans rien avoir a compiler, t'as juste a executer pyvst.py + installer python au depart; je te conseille d'installer ipython comme interpreteur python, ca permet de faire pas mal de choses depuis l'interpreteur, style ce que tu peux faire sous un shell normal sous unix).

http://www.ar.media.kyoto-u.ac.jp/members/david/pyvst.zip

Je suis desole pour le bordel a l'interieur, mais je connais pas VS pour voir comment il organise ses trucs entre sources, binaires, projets et solutions, puis en plus, je sais pas comment forcer les chemins pour trouver les librairies sous windows (equivalent de rpath).

Anonyme

521397

332 Posté le 05/09/2006 à 12:08:10

Citation : Ca depend de ta distribution. Perso, j'utilise essentiellement debian et ubuntu, qui toutes les deux fournissent le tout package. Compiler soi meme des cross compilateurs est plus difficile (le compilo, ca va, mais la libc, c'est deja plus tordu), par contre, mais ca se fait. Je l'ai fait pour compiler des programmes sur mon routeur qui tourne sous arch MIPS. Apres, c'est sur que si tes projets dependent de 30 librairies que tu vas devoir elles aussi cross compiler, ca va devenir tendu... Je pense qu'une fois que j'aurais un PC avec l'architecture VT, styles les core, j'utiliserais xen pour compiler des projets sous windows depuis linux.

oui en effet ca semble assez complexe, mais je vuex ca pour compiler des applications OpenGL + SDL (toutes les autres lib que j'utilise sont dans les sources et compilé en statique). J'ai de la chance des mecs ont fait les scripts pour ca (installé mingw opengl et sdl win32) et utilisé les autotools, la je vais tester voir ce qui se passe... merci pour l'info ;)

zieQ

466

Posteur·euse AFfamé·e

Membre depuis 22 ans

333 Posté le 05/09/2006 à 14:07:44

Et ben Pov Gabou t'as pas vraiment de recul pour faire un jugement objectif. C'est évident que tout outil, au premier abord, ça demande un temps d'adaptation. A moins que tu m'avoues n'avoir jamais galéré sur une ligne de commande sous linux ou à créer un makefile, auquel cas je te traite de menteur :lol:

. Honnettement, cracher sur des trucs que tu connais pas, c'est un peu facile.

zieQ

466

Posteur·euse AFfamé·e

Membre depuis 22 ans

334 Posté le 05/09/2006 à 14:29:35

Pilo, si tu veux un conseil, oublie la compilation sous linux si t'es sous windows, tu vas te faire chier à mettre ça en place pour un gain en temps pas forcément énorme. Pour la mise au point de tes programmes, il est préférable d'utiliser un compilateur rapide comme VC ou Digital Mars, tu pourras ainsi tester rapidement des nouveaux trucs. Ensuite, pour la version release, utilise le compilateur qui te plait le plus, ou mieux celui qui produit le code le plus optimisé et basta. Pour ça, il faut un outil qui te permet de créer des fichiers de projets/makefile pour chacun des compilos. Moi j'utilise cmake mais on peut prendre ce qu'on veut, voire les faire à la main si le projet est relativement simple (car c'est chiant à maintenir).

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

335 Posté le 05/09/2006 à 14:46:15

Citation :
Et ben Pov Gabou t'as pas vraiment de recul pour faire un jugement objectif. C'est évident que tout outil, au premier abord, ça demande un temps d'adaptation. A moins que tu m'avoues n'avoir jamais galéré sur une ligne de commande sous linux ou à créer un makefile, auquel cas je te traite de menteur . Honnettement, cracher sur des trucs que tu connais pas, c'est un peu facile.

Je critiquais essentiellement 2 choses:
- l'absence de ligne de commande potable sous windows
- l'absence de standart pour les librairies et cie (equivalent des lib/include, quoi), et tout ce qui va avec pour utiliser les librairies tierses.

Pour le reste, c'est sur que la difficulte avec VS c'est parce que je connais pas, mais c'est pas vraiment ca que je critiquais.

Citation :
Pilo, si tu veux un conseil, oublie la compilation sous linux si t'es sous windows, tu vas te faire chier à mettre ça en place pour un gain en temps pas forcément énorme.

Je maintiens que si ton projet est essentiellement unix, et que tu ne depends pas trop d'autres librairies, ca marche bien, je le fais pour certains projets sans pb. Parce que le pb avec VS (digital mars, je connais pas), c&est pas seulement le systeme build, mais aussi qu'il y a pas mal de standart POSIX non pris en compte. Alors ca peut aller du simple __int32 a la place de int32_t a des trucs nettement plus chiants.

zieQ

466

Posteur·euse AFfamé·e

Membre depuis 22 ans

336 Posté le 05/09/2006 à 15:00:55

Citation : Pilo, si tu veux un conseil, oublie la compilation sous linux si t'es sous windows, tu vas te faire chier à mettre ça en place pour un gain en temps pas forcément énorme.

Je maintiens que si ton projet est essentiellement unix, et que tu ne depends pas trop d'autres librairies, ca marche bien, je le fais pour certains projets sans pb.

Eh oui mais je parlais d'un projet windows, pas unix, ne me fait pas dire ce que je n'ai pas dit ;)

Citation :
Je critiquais essentiellement 2 choses:
- l'absence de ligne de commande potable sous windows
- l'absence de standart pour les librairies et cie (equivalent des lib/include, quoi), et tout ce qui va avec pour utiliser les librairies tierses.

C'est vrai que le système de build windows n'est pas terrible. Mais personnellement, pour avoir eu des déboires sous linux, je ne trouve pas que celui de linux soit bcp mieux. D'abord il y a la gestion des versions différentes de packages pour les dépendances qui est trop galère, et le système de makefile/autotools franchement pas intuitif où il est très facile de faire des erreurs. J'ai fait mon choix, c'est ni l'un ni l'autre !

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

337 Posté le 05/09/2006 à 15:10:21

Citation :
Eh oui mais je parlais d'un projet windows, pas unix, ne me fait pas dire ce que je n'ai pas dit

Mais Pilo parle d'un projet compile avec gcc (mingw) avec SDL, donc je pense qu'on est proche d'un projet unix conventionnel.

Pour automake/autoconf, c'est clair que c'est merdique, perso, j'utilise scons. Le pb de dependances par contre, je trouve ca mieux gere que sous windows. Ce qui est penible sous windows, c'est que tout est different, sans raison valable le plus souvent.

zieQ

466

Posteur·euse AFfamé·e

Membre depuis 22 ans

338 Posté le 05/09/2006 à 15:27:21

Citation : Mais Pilo parle d'un projet compile avec gcc (mingw) avec SDL, donc je pense qu'on est proche d'un projet unix conventionnel.

Ben c'est pas clair, j'utilise SDL avec Visual C++ pour faire du multiplateforme, c'est donc ni unix, ni windows spécifiquement.

Citation : Ce qui est penible sous windows, c'est que tout est different, sans raison valable le plus souvent.

Ca marche aussi si tu remplaces windows par unix, linux, mac osx, etc. :lol:

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

339 Posté le 05/09/2006 à 15:36:48

Ben non, puisque tous les OS "communs" sur machine "commune" tournent sur du unix. Quand tu regardes la plupart des gros projets open source, de apache a python en passant par mozilla, la plateforme la plus chiante a gerer niveau compilo + build, c'est toujours MS.

miles1981

8370

Je poste, donc je suis

Membre depuis 21 ans

340 Posté le 05/09/2006 à 17:19:18

VS2005 Express a d'autres limitations :
- pas d'optimisation globale
- pas de plug-in

J'ai jamais eu de souci avec des gestionnaires de source, je fais aussi du SVN avec Tortoise, ça marche bien.

La STL de Microsoft est dépréciée en grande partie pour tenter de favoriser les itérateurs sécurisés - google + sutter + secured iterators -, c'est une bonne idée, ils sont peut-être allés trop loin en dépréciant une partie de la SL du C aussi... - memcpy, ... ont des amis memcpy_s, ... -

Boost n'est pas fourni en package compilé, et je trouve que c'est plutôt à Boost.org qu'il faut se plaindre. Je n'ai aps encore tenté de rajouter Boost.Python, mais avec ce que tu as fait, ça risque d'être rapidement le cas.

Je compile aussi aprfois Qt4 pour VS, et franchement, je n'ai pas plus de soucis que sous Linux.

Pour répondre à la question ASP, c'est oui, il suffitd e prendre le bon VS, et tout est fourni - et l'indenteur est bien mieux que sous 99% des outils Linux -

VS gère aussi les dépendances, et implicitement, ça se voit avec Intellisense.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

341 Posté le 05/09/2006 à 17:38:45

Citation :
Boost n'est pas fourni en package compilé, et je trouve que c'est plutôt à Boost.org qu'il faut se plaindre. Je n'ai aps encore tenté de rajouter Boost.Python, mais avec ce que tu as fait, ça risque d'être rapidement le cas.

Oui, mais la faute est quand meme en partie due a MS et ses outils non standart pour le build. Tous les projets que j'utilise, qui sont en general les references pour leur sujet (Atlas, fftw, sndfile, boost, etc...) ont dans la FAQ un truc special pour microsoft, c'est quand meme dingue !

Bon, sinon, parce que ca va finir en vulgaire ms contre * ( :oops:

), j'annonce que j'arrive enfin a faire tourner un plug in vst, et a tranformer des entrees au travers du plug. Bon, ca vaut ce que ca vaut (ie pas grand chose), mais avec le again en exemple VST, sur mon P4 1.8 Ghz, ca me prend 2 secondes pour traiter une heure de son @ 48 khz avec des blocs de 1024 samples, et j'ai rien optimise (entr autre, le vecteur de sortie est a chaque fois realloue). Ca devrait donc rester utilisable pour tester d'autres plugs. Ca plante avec adelay, mais je pense que c'est parce que j'ai pas verifie comment marche le multi channel, et adelay a une sortie sterreo pour une entree mono, ca doit venir de la.

Je trouve que c'est pas mal, ca a du me prendre 25 heures de codage a tout casser, avec decouverte de VS 8, boost python, revision de C++ et decouverte du fonctionnement hote VST. Bon point pout boost python, en tout cas, et ca confirme mon impression que le C++ reste interessant comme langage intermediaire pour faire le plombage entre le C et d'autres langages plus haut niveau.

Anonyme

521397

342 Posté le 05/09/2006 à 18:04:07

Citation : Pour répondre à la question ASP, c'est oui, il suffitd e prendre le bon VS, et tout est fourni - et l'indenteur est bien mieux que sous 99% des outils Linux -

le 1% c'est emacs? rien a faire je préfère toujours celui de visual... mais c'est une question de préférence.

Ensuite mon projet est en fait un truc linux à la base, porter sous OSx (je dois l'admetre, sans problème une fois que j'ai remplacer les -lblabla par ce qu'il fallait), et je veux le faire tourner sous windows, mais la... meme avec cygwin tout installé, ben j'ai encore des erreurs sur des link (statique) qui fonctionne ailleur...
la cross compilation à première vu à pas mieux marcher mais il faut que je regarde de plus pret.

j'avais pensé à la solution visual studio, mais ca risque d'etre lourd à gérer si je dois modifier sln et projet juste pour compiler.

Pour ce qui est des autotools, je trouvais ca pratique mais pas vraiment simple... , j'irai faire un tour du coté de scons

Merci pour tous les conseils ;)

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

343 Posté le 05/09/2006 à 18:10:45

Citation :

le 1% c'est emacs? rien a faire je préfère toujours celui de visual... mais c'est une question de préférence.

A ce niveau la, c'est clairement du niveau de la pref personnelle, parce que perso, j'utilise vim, et ca me va tres bien pour tous mes travaux d'edition. emacs me convient pas a cause de mes pbs de RSI (les ctrl + *, c'est affreux), et bon, le truc de visual, j'ai pas reussi a lui faire coloriser mes trucs, donc bon, j'ai pas capte la puissance du truc ;)

En fait, je suis assez impressionne des perfs de l'hote. C'est vrai que python fait pas grand chose, mais quand meme, le cout du wrapping est negligeable pour des tailles de blocs raisonnable (1024). Pour des petits tailles (genre 64), faudrait que je regarde ce que ca donne avec un truc style psyco.

Citation :
Pour ce qui est des autotools, je trouvais ca pratique mais pas vraiment simple... ,

Non mais deja la lourdeur du truc, c'est phenomenal. Tu change un Makefile.am, et hop que ca reprend 1 minute facile pour regenerer le truc. En lus, c'est pas portable sous autre chose qu'unix, s'il y a une erreur dans ton script, faut avoir le courage de regarder un script de 100000 lignes, etc...

miles1981

8370

Je poste, donc je suis

Membre depuis 21 ans

344 Posté le 06/09/2006 à 11:35:55

Citation : Oui, mais la faute est quand meme en partie due a MS et ses outils non standart pour le build. Tous les projets que j'utilise, qui sont en general les references pour leur sujet (Atlas, fftw, sndfile, boost, etc...) ont dans la FAQ un truc special pour microsoft, c'est quand meme dingue !

Sachant que Boost a son propre outil de compilation, c'est pas la bonne excuse ;) Et il y a un truc pour chaque compilo tout de même.

Les autotools, j'aime bien, j'arrive à faire des trucs sympas, des vérifs dans tous les sens, ... et la regénération des Makefile lorsqu'on change un Makefile.am, c'est pas dérangeant, c'est rapide chez moi, même si le projet est gros avec des goals ajoutés à la main dedans.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

345 Posté le 06/09/2006 à 18:14:44

Citation :
Sachant que Boost a son propre outil de compilation, c'est pas la bonne excuse

Je parlais en general, pas specifiquement pour boost (qui est de toute facon hors competition, car utilisant le C++, le langage le plus chiant au monde au niveau standart tant tu as presque un nouveau langage pour chaque compilo).

Citation :
Les autotools, j'aime bien, j'arrive à faire des trucs sympas, des vérifs dans tous les sens, ... et la regénération des Makefile lorsqu'on change un Makefile.am, c'est pas dérangeant, c'est rapide chez moi, même si le projet est gros avec des goals ajoutés à la main dedans.

T'es vraiment bizarre, en fait :diable:

Pour jack, qui est un projet relativement simple (a peine 100 sources, 14 Makefile.am), ca prend 1m30 pour generer un projet (autoreconf + ./configure) usr mon portable a base de P4, quand meme. Donc si tu changes un makefile.am, ca va prendre a peu pres ce temps pour retester. Le fait que de gros projets open source (kde, ardour) cherchent a s'eloigner du truc est un signe a mon avis que ca a fait son temps.

Avoir besoin de 4 langages(perl + m4 + shell + Makefile), au moins 5 outils tous interdependants (aclocal + autoconf + automake + libtool + autoheader), qui genere un script shell de 25000 lignes, c'est quand meme tordu. Sans compter la doc qui est extremement pauvre et eparpillee un peu partout

Anonyme

521397

346 Posté le 06/09/2006 à 18:24:59

Citation : Avoir besoin de 4 langages(perl + m4 + shell + Makefile), au moins 5 outils tous interdependants (aclocal + autoconf + automake + libtool + autoheader), qui genere un script shell de 25000 lignes, c'est quand meme tordu. Sans compter la doc qui est extremement pauvre et eparpillee un peu partout

oue en fait +1 la dessus.... Scons semble etre vraiment un cran au dessus. (sur les conseils récolté ici je remplace ;) )

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

347 Posté le 06/09/2006 à 18:40:38

Ce que je trouve puissant dans scons, c'est de ne pas tenir compte de l'environnement, et surtout d'avoir un vrai langage.

Maintenant, ca a pas mal de defauts:
- pas de prise en compte d'un equivalent de libtool (mais bon, ca marche pas sous windows non plus, libtool)
- la gestion des options est pas tres convivial
- probleme de lenteur ? Perso, j'ai pas eu de problemes avec mes petits projets, et meme un truc comme ardour qui est deja assez lourd est quand meme plus rapide a etre update que autoconf and co. Puis des projets comme blender ou quake l'utilise aussi.
- t'as pas toutes les macro de autoconf. Par exemple, j'ai du ecrire mon propre code pour tester blas et lapack, mon propre code pour faire un tarball des sources, mon propre code pour le versioning de librairies... Mais le fait que tu puisses le faire est cependant un signe du bien fonde de l'outil, car etendre autoconf de cette maniere est quasiment impossible.

Si tu veux maitrisier scons, je te conseille de regarder ardour (qui mixe des librairires sous autoconf), blender et csound.

Anonyme

521397

348 Posté le 06/09/2006 à 19:14:24

Je vais jeter un coup d'oeil a ces sources la, mais contrairement à autotools ou j'avais du regarder dans d'autre projet comment c'était fait, la ca me semble relativement simple... meme pour tester les trucs genre SDL etc.

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 23 ans

349 Posté le 06/09/2006 à 19:49:20

Y a des choses qui sont pas simples, quand meme. Typiquement, faire un tar ball des sources (l'equivalent du make dist), le unit testing, les specialisations selon plateformes et/ou outil.

Par contre, un truc excellent, je sais pas si t'as vu, c'est qu'il y a une version self contained que tu peux inclure ton projet (parce que scons est pas encore super repandu non plus).

C'est dommage qu'ils aient loupe le coche kde (kde, pour la version 4, etait sur le point d'utiliser scons, mais ils ont prefere cmake a la fin, pour des raisons que je trouve un peu bizarres), ca aurait fait une grossepub, comme le passage a subversion.

Anonyme

521397

350 Posté le 06/09/2006 à 22:00:59

Scons commence a etre bien répendu quand meme, et vu ses qualitésn ca devrais encore évolué!
Jusque la je dois dire que j'aime bcp!! surtout si on peut inclure une version dans le projet! je compte pas distribué ce sur quoi je travail, mais je veux pouvoir le compiler sur des machines mac, linux et windows, et c'est toujours embant de demander au propriétaire de la machine d'installer un truc...

pour ce qui est des unit test etc, étant donné que j'ai a peu pret aucune formation en génie logiciel, et que donc je vois tout juste ce que ca peut etre, ca me dérange pas trop... Sincèrement la je me mord les doigt d'avoir choisit les autotools avant!!

< Liste des sujets
Charte

Liste des modérateurs