2.3.4 Installer à partir de l'arbre source de développement

Attention : Vous devez lire cette partie seulement si vous voulez nous aider à tester notre nouveau code. Si vous souhaitez seulement faire fonctionner MySQL sur votre système, vous devriez utiliser la distribution d'une version standard (que ce soit une distribution sous forme de sources ou de binaire).

• Téléchargez BitKeeper à partir de http://www.bitmover.com/cgi-bin/download.cgi . Vous aurez besoin de Bitkeeper 2.0 ou supérieur pour accéder à notre dépôt.
• Suivez les instructions pour l'installer.
• Après avoir installé BitKeeper , commencez par vous déplacer dans le répertoire à partir duquel vous voulez travailler, et lancez l'une des commandes suivantes pour dupliquer la branche MySQL de votre choix :Pour dupliquer la branche 3.23, utilisez cette commande :

  shell> bk clone bk://work.mysql.com:7000 mysql-3.23

  Pour dupliquer la branche 4.0, utilisez cette commande :

  shell> bk clone bk://work.mysql.com:7001 mysql-4.0

  Pour dupliquer la branche 4.1, utilisez cette commande :

  shell> bk clone bk://work.mysql.com:7004 mysql-4.1

  Dans les exemples précédents, l'arbre source sera déposé dans les sous-répertoires mysql-3.23/ , mysql-4.0/ , ou mysql-4.1/ de votre répertoire courant.Le premier téléchargement de l'arbre source peut prendre un certain temps, selon la vitesse de votre connexion. Soyez patients.
• Vous aurez besoin de GNU autoconf 2.52 , de automake 1.5 , de libtool 1.4 , et de m4 pour lancer la prochaine série de commandes.

  shell> cd mysql-4.0 shell> bk -r get -Sq shell> aclocal; autoheader; autoconf;  automake; shell> ./configure  # Ajoutez ici vos options favorites shell> make

  Si vous obtenez des erreurs étranges pendant cette étape, vérifiez bien que vous avez vraiment installé libtool !

  Une collection de nos scripts de configuration les plus courants de trouve dans le sous-répertoire BUILD/ . Si vous êtes fainéants, vous pouvez utiliser BUILD/compile-pentium-debug . Pour compiler sur une architecture différente, modifiez ce script en enlevant les drapeaux spécifiques au Pentium.

• Quand la compilation est achevée, lancez make install . Prenez garde sur des machines de production. Cette commande pourrait écraser votre installation actuelle. Si vous avez une autre installation de MySQL, nous vous recommandons de lancer ./configure avec des valeurs des options prefix , with-tcp-port , et unix-socket-path différentes de celles de votre serveur de production.
• Torturez votre nouvelle installation et tentez de faire planter les nouvelles fonctionnalités. Commencez par lancer make test . Suites de tests MySQL .
• Si vous avez échoué avec l'étape make et que la distribution ne compile pas, envoyez un rapport de l'incident à bugs@lists.mysql.com . Si vous avez installé la dernière version des indispensables outils GNU, et qu'ils échouent dans l'analyse de vos fichiers de configuration, envoyez aussi un rapport. D'autre part, si vous exécutez aclocal et que vous obtenez l'erreur command not found ou un problème du même type, n'envoyez pas de rapport. A la place, assurez vous que les outils nécessaires sont bien installés et que votre variable PATH est configurée de telle façon que votre interpréteur de commandes les trouvent.
• Après la première opération bk clone pour obtenir l'arbre source, vous devez lancer régulièrement bk pull pour obtenir les mises à jour.
• Vous pouvez examiner l'historique des changements de l'arbre avec toutes les différences en utilisant bk sccstool . Si vous apercevez des différences anormales ou sur lesquelles vous avez des questions, n'hésitez pas à envoyer un e-mail à internals@lists.mysql.com . De même, si vous pensez avoir une meilleure méthode pour traiter un problème, envoyez un e-mail accompagné d'un patch à la même adresse. bk diffs vous fournira un patch après que vous ayez fait vos changements aux sources. Si vous n'avez pas le temps de coder votre idée, envoyez en juste une description.
• BitKeeper dispose d'une aide agréable à laquelle vous pouvez accéder via bk helptool .
• Veuillez noter que chaque commit ( bk ci ou bk citool ) postera un message avec un aperçu des changements à notre liste de diffusion interne, à la façon habituelle des propositions openlogging.org avec seulement les commentaires des changements. Généralement, vous n'aurez pas besoin d'utiliser commit (l'arbre public interdisant les bk push ), mais plutôt d'utiliser la méthode bk diffs décrite plus haut.