Définir un environnement d'exécution

Question

Je dois définir un environnement d'exécution pour mon développement. La première idée est bien sûr de ne pas réinventer la roue. J'ai téléchargé macports, utilisé easy_install, essayé fink. J'ai toujours eu des problèmes. À l'heure actuelle, par exemple, je ne suis pas en mesure de compiler scipy car le programme d'installation de MacPorts souhaite télécharger et installer gcc43, mais cela ne compile pas sur Snow Leopard. Un bogue est ouvert pour ce problème, mais je suis fondamentalement lié à eux pour que mon runtime soit utilisable.

Une technique que j’ai apprise il ya quelque temps consiste à écrire un fichier makefile pour télécharger et construire le runtime / libs avec des versions clairement spécifiées de bibliothèques et d’utilitaires. Ceci est antérieur à l’approche MacPorts / fink / apt, mais vous avez beaucoup plus de contrôle là-dessus, même si vous devez tout faire à la main. Bien sûr, cela peut devenir un cauchemar si le moteur d'exécution augmente, mais si vous rencontrez un problème, vous pouvez utiliser patch et résoudre le problème sur le package téléchargé, puis générez-le.

J'ai plusieurs questions:

• Quelle est votre technique pour préparer une collection runtime / library bien définie pour votre développement?
• MacPorts / fink / what me donne-t-il la même souplesse de rehacking en cas de problème?
• Compte tenu de ma solution makefile, lorsque mon logiciel est enfin disponible au téléchargement, quelles suggestions faites-vous pour résoudre les problèmes potentiels entre mon environnement de développement et la plate-forme proprement dite sur les ordinateurs de mes utilisateurs?

Modifier : ce que je ne comprends pas en particulier, c'est que les autres projets ne me donnent pas d'indices. Par exemple, je viens de télécharger scipy, une bibliothèque complexe avec de nombreuses dépendances. Les développeurs doivent avoir tous les paramètres de configuration avant de travailler dessus. Malgré cela, rien dans le fichier svn ne crée cet environnement.

Modifier : ajout d'une prime à la question. Je pense que c'est un problème important et qu'il mérite davantage de réponses. Je considérerai au mieux ces réponses avec des exemples du monde réel avec une attention particulière pour toutes les questions soulevées et leur solution.

Autres questions à inspirer pour le Bounty:

• Effectuez-vous des tests sur votre environnement (pour vérifier une installation correcte, par exemple sur une machine d'intégration)?
• Comment incluez-vous votre environnement au moment de l'expédition? Si c'est C, est-ce que vous le liez statiquement ou livrez la bibliothèque dynamique en bricolant LD_LIBRARY_PATH avant d'exécuter l'exécutable? Qu'en est-il du même problème pour Python, Perl et autres?
• Vous en tenez-vous au runtime ou le mettez-vous à jour au fil du temps? Téléchargez-vous " trunk " paquets de vos bibliothèques de dépendances ou une version fixe?
• Comment gérez-vous les situations suivantes: library foo nécessite Python 2.5, mais vous devez développer python 2.4, car la barre de bibliothèque ne fonctionne pas avec python 2.5?

Answer 1

Nous utilisons un script CMake qui génère des Makefiles qui téléchargent (principalement via SVN) / configure / construisent toutes nos dépendances. Pourquoi CMake? Multi plateforme. Cela fonctionne très bien et nous soutenons l’invocation de scons / autopain / cmake. Comme nous construisons sur plusieurs plates-formes (Windows, MacOSX, de nombreuses variantes de Linux), nous prenons également en charge différents indicateurs de compilation, etc. basés sur le système d'exploitation. En règle générale, une bibliothèque a une configuration par défaut et si nous rencontrons un système nécessitant une configuration spéciale, celle-ci est remplacée par une configuration spécialisée. Cela fonctionne assez bien. Nous n'avons pas vraiment trouvé de solution prête qui conviendrait à notre objectif.

Cela étant dit, il s’agit d’un PITA pour le rendre opérationnel. Il existe de nombreux boutons à tourner pour prendre en charge plusieurs systèmes d’exploitation. Je ne pense pas que cela va devenir un cauchemar de maintenance car les dépendances sont assez fixes (les bibliothèques sont mises à jour régulièrement, mais nous en introduisons rarement de nouvelles).

Answer 2

virtualenv est bon, mais il ne peut pas faire de magie - par exemple si vous voulez utiliser une bibliothèque qui DOIT simplement avoir Python 2.4 et une autre qui a absolument besoin de 2.5, vous n’êtes pas chanceux. Virtualenv (ou tout autre outil) ne peut pas non plus aider lorsqu'il existe une toute nouvelle version d'un système d'exploitation et que la moitié des outils ne le supporte pas encore, comme vous l'avez mentionné pour Snow Leopard: certains problèmes sont tout simplement impossibles à résoudre (deux). bibliothèques ayant des besoins absolument conflictuels dans la même version), d’autres nécessitent juste de la patience (jusqu’à ce que tous les outils dont vous avez besoin soient transférés dans la nouvelle version du système d’exploitation, il vous suffit de vous en tenir à la version précédente du système).