Latest revision as of 02:13, 5 March 2022

Languages:

English    Deutsch    Français    日本語

Cette page couvre la compilation d'OpenSimulator à partir du code source pour plusieurs plateformes. S'il vous plaît, aidez-nous à garder cette page à jour pour au fur et à mesure que le projet progresse. Si vous voulez simplement lancer une instance d'OpenSimulator, téléchargez et lancez la version binaire à la place. Dans la plupart des cas, cette version fonctionne très bien.

[edit] Obtenir le code source

Allez à la page de téléchargement pour trouver des instructions et la dernière version du code source. Si vous voulez le code de développement courant,( comme par exemple la branche maître Git) allez à la page Developer_Documentation#Source_Code_Repository_Access.

[edit] Compiler

Autant cette page est longue, autant la compilation d'OpenSimulator est rapide. Reportez-vous au fichier BUILDING.txt inclus dans la distribution elle-même pour trouver des instructions simplifiées.

[edit] Conditions

OpenSimulator 0.9.0.x nécessite soit

• .NET Framework 4.0 sur Windows
• Mono sur Linux ou Mac. Mono 2.10.8 est la version minimale.

Vous pouvez également avoir besoin de l'outil nant.

OpenSimulator >= 0.9.1 (y compris le master actuel) nécessite

• .NET Framework 4.6 sur Windows
• Mono sur Linux ou Mac. Mono 5.12 est la version minimum recommandée.
  

Note: plutôt que d'utiliser les paquets Mono de votre distribution Linux, qui peuvent manquer de composants requis, veuillez installer à partir du dépôt officiel de Mono pour votre distribution. Il est recommandé de compiler avec msbuild.

D'autres plateformes peuvent avoir leurs propres distributions mono, ou peuvent avoir besoin de compiler mono.

D'autres bibliothèques utilisées par OpenSimulator peuvent être trouvées dans notre dépôt git opensim-libs :

git clone git://opensimulator.org/git/opensim-libs

La bibliothèque libOpenMetaVerse utilisée peut être trouvé sur https://bitbucket.org/opensimulator/

Vous devrez peut-être les compiler pour votre plate-forme, en particulier les bibliothèques non gérées comme les bibliothèques de code natif Bullet ou ODE.

[edit] Microsoft Windows

[edit] Compilateurs supportés

• Visual Studio Community 2017
• Ou toute autre version qui supporte la version .Net. Au moins VS2010 pour les versions antérieures à 0.91, VS2015 pour les versions 0.91 et ultérieures.
• OpenSimulator >=0.9.2.0 peut compiler pour .Net Framework 4.8 en utilisant runprebuild48.bat au lieu de runprebuild.bat ci-dessous et avec VS2017/19/22

[edit] Compiler dans un IDE

1. Lancez "runprebuild.bat".
2. Ouvrez le fichier "OpenSim.sln" résultant dans L'IDE Visual Studio.
3. Sélectionnez la configuration Debug ou Release
4. Menu Build -> Build Solution.

[edit] Compiler en ligne de commande

1. Lancez "runprebuild.bat".
2. Lancez le fichier "compile.bat" résultant.

[edit] Linux et autres plates-formes mono

[edit] Préparer la compilation

Pour créer les différents fichiers du projet, exécuter dans le dossier opensim :

 ./runprebuild.sh

[edit] Compiler avec Nant

Sur certaines versions de mono, en particulier les anciennes versions peuvent nécessiter d'utiliser l'utilisation de nant pour compiler correctement OpenSimulator, dans ce cas il suffit d'exécuter :

nant

[edit] Compiler avec xbuild

Sur les versions mono, vous pouvez simplement utiliser xbuild. (msbuild est recommandé pour la version 0.9.1.0.0+)

 xbuild

xbuild n'est plus recommandé sur mono 5.x, mais fonctionne toujours actuellement (5.12)

>>>> L'outil xbuild est obsolète et sera supprimé dans les prochaines mises à jour, utilisez plutôt msbuild <<<<

Sur les versions mono plus récentes, la configuration de la version peut donner un certain gain de performance, mais vous perdez certaines capacités de débogage.
Compiler avec la configuration Release :

   xbuild /p:Configuration=Release

[edit] Compiler avec msbuild

Pour Opensim 0.9.1 vous pouver encore utiliser xbuild mais Mono recommande l'utilisation de msbuild. Pour cela, vous devrez peut-être installer le paquet msbuild en plus de mono-complete. (Actuellement, msbuild est inclus si vous installez mono-complete, sur Ubuntu, à partir des dépôts mono officiels. https://www.mono-project.com/download/stable/#download-lin ).

Utilisez xbuild sur les autres cas en dernier recours.

Des améliorations récentes, en particulier sur le runtime JIT, justifient la compilation en configuration Release, mais vous perdez certaines capacités de débogage.

Compiler avec la configuration de débogage :

  msbuild

Compiler avec la configuration Release :

  msbuild /p:Configuration=Release

Compiler avec la configuration debug et afin que le fichier détaillé OpenSim.log puisse être lu avec un éditeur de texte :

  msbuild /p:Configuration=Debug /fileLogger /flp:logfile=opensim.log /v:d

Vous pouvez spécifier les valeurs suivantes pour définir le niveau de détail du fichier OpenSim.log :

  q [quiet], m [minimal], n [normal], d [detailed] and diag [diagnostic].

Pour compiler pour .Net Framework 4.8 avec mono >=6.12. vous pouvez exécuter runprebuild48.sh au lieu de runprebuild.sh ci-dessus. Toutefois, il n'y a pas beaucoup d'intérêt à faire cela, si ce n'est aucun.

[edit] Compilation anticipée (Ahead of Time compilation) (AOT)

Comme vous le savez tous, les fichiers *.exe et .dll créés par le processus de compilation ci-dessus ne contiennent pas de code natif pour la machine.
Avec ces fichiers, le code natif requis par l'ordinateur est créé au moment de l'exécution, selon les besoins, dans un processus appelé Just in Time (JIT)(compilation à la volée).
Il est possible de faire une autre niveau de compilation sur ces fichiers pour créer un code natif, qui sera prêt au démarrage du programme. C'est le processus AOT (Ahead of time process).
Comme le JIT se fait à l'exécution, il dispose d'un temps limité pour effectuer des optimisations de code étendues, AOT, en revanche, peut tout faire.
AOT devrait ainsi être plus rapide à charger, économiser la mémoire nécessaire au travail du JIT et réduire la latence due à la génération de code lorsqu'une nouvelle section de code est nécessaire.
De cette façon, AOT contribue à réduire l'énorme écart de performance entre le C# et un langage plus approprié comme le C++, même si le JIT peut effectuer une certaine optimisation en fonction de l'état d'exécution du code, ce que AOT ne peut pas faire. (si vous pensez que c# est aussi rapide qu'un code C++ efficace, mieux vaut fumez autre chose...)
En fait, aussi bien .net que mono utilisent AOT sur leurs composants lors de l'installation
Le JIT sera toujours actif et compilera un autre code au moment de l'exécution. OpenSim et les parties utilisées du framework .net/mono en dépendent.

Pour Linux, la version 0.9.2.0 inclut désormais les scripts makeaot.sh et cleanaot.sh pour aider à tester AOT.
Lancez makeaot.sh après l'étape de compilation ci-dessus, pour générer les fichiers de code natif. L'option -O=all doit être ajoutée à mono lors de l'exécution de opensim.exe, ex:

 mono --desktop -O=all OpenSim.exe

Le script cleanaot.sh supprime les fichiers binaires utilisés par AOT. Vous devez l'exécuter si vous recompilez le code (pour être protégé même si vous exécutez makeaot).
N'OUBLIEZ PAS de lancer makeaot.sh ou cleanaot.sh après la recompilation!
Les fichiers générés sont spécifiques à cette machine. Ne pas copier les fichiers de code natif sur une autre machine, sauf si elle est absolument identique
Les .exe et .dll originaux sont toujours nécessaires

AOT est également possible dans Windows, mais en utilisant différents outils, et ceux-ci ajoutent des choses au dépôt central sur la machine, plus difficile à isoler et à maintenir. voir ngen

Les Macs sont.. Les Macs.. Les futurs modèles pourraient totalement interdire le JIT, comme le font les produits mobiles d'Apple. Le Mono AOT sur les Macs actuels pourrait fonctionner comme sur Linux

En pratique, ne vous attendez pas à un chargement plus rapide. De plus, comme la compilation est différente, elle peut ajouter de nouveaux problèmes. Donc, testez avec soin.
Les problèmes de performance d'Opensim concernent principalement son propre code, les terribles mauvais protocoles de communication, l'utilisation d'un mauvais code .net/mono framework (qualité de la démo dans les mêmes cas), etc.
Et bien sûr, GC éternellement cassé.
But... well every ns counts..

[edit] Configuration

Voir Configuration.