Windows7/8/10でRustを別ドライブに展開する際のTIPS
Windows7/8/10でRustを別ドライブに展開して使用したかったのだが、公式サイトや他サイトさんの手順通りにやってもうまく行かなかったので、メモがてら実に 半 年 以 上 ぶ り の投稿。
使用したバージョンは「Rust 1.48.0」「Visual Studio Build Tools 2019」。これらをメインのドライブではなく、別ドライブに展開する。
仕事にかまけて展開したのが結構前のことなので、展開時の詳しいエラーコードなどはほとんど覚えていない状態だが、同じようなことをしようとしてる人（・・・いるんだろうか？）のためにTIPSとしてブログに掲載。
まず、自分の環境下でうまくいかなかった際と事象としては経緯も含めてこんな感じ。
- Rust公式サイトよりrust-init.exeをダウンロードする。
- ダウンロードしたrust-init.exeを起動したらDOS窓インストールだったため、本来インストールしたかったドライブ側にrust-init.exeをインストールしたいディレクトリに移動して展開した。
- とりあえずなんのトラブルもなくRust本体のインストールは無事完了。
- 最初からセオリーを無視しているため、どうせパスも通さん状態で普通にコマンド叩いても動かんだろうと察したためパスを通すのはとりあえず後回しにしてとりあえず動作確認を優先しようとした。
プロジェクトを作りたいディレクトリにcdして「実行パス\cargo new hello –bin」で公式とか他サイトさんの手順通りにコマンドを叩く。 - 「hello」プロジェクトが無事作成される。（計画通り！とほくそ笑む）
そして、いざ「実行パス\cargo run」でコンパイルしようとする・・・が、
他サイトさんでとりあげられることの多い恒例の「error: linker `link.exe` not found」。
ふふん。ここまでは想定範囲内だ(｀・ω・´)
（というか、普通に窓にも「Visual Studio Build ToolsのC++コンパイラがないとコンパイルできへんで」って英語で警告出てるしね・・・）
いくら、Rustのドキュメンテーションが他言語に比べて優しくないとは言え、今やファミコンとかスーパーファミコン時代のようにインターネットが普及していなかった時代ではないのだ。
他サイトさんを参考にRustをインストールしたところと同じドライブにVisual Studio Build Toolsをインストールした。
やっぱり他サイトさんは神っスわ！
再び「実行パス\cargo run」を実行。
よーし、これでコンパイル通っｔ・・・・ねぇよ！！！
なぜだ・・・？
元々がセオリー通りのインストールをしていないので、パスを通していない、レジストリに値が行っていないとか原因としては色々考えられるんだけど、環境構築の時点でつまづくとかいろんなフレームワークとかDBMSとかその他諸々を組み合わせたコンパチ開発環境の構築ではあるまいし・・・。
とりあえず、動作確認を優先させるために後回しにしようと思っていたパスを通してから、もう一度実行してみるもののやはりコンパイルが通らない。
cargo runそのものは当然普通に実行できるようになったものの、実行後に相も変わらず「error: linker `link.exe` not found」が発生してコンパイルができない。
相当前にRubyでMySQL接続環境を構築した際に、MySQL用のアダプタのバイナリファイルを直接移動させたこともあったため、cargoの中にlink.exeの複製が必要なのかとも思い（まぁ普通に考えれば実際はlink.exeは他の依存する実行ファイルともリンクしているはずなのでそんなことはないだろうけど）、Visual Studio Build Tools側からのインストールディレクトリより、link.exeを複製してみることを試した。
「Visual Studio Build Toolsのインストールディレクトリ\VC\Tools\MSVC\バージョン\bin」からlink.exeを引っ張り出してきて、Rustのcargo.exeが入っている場所に複製。
結果：余計にエラーがひどくなりました＜(^o^)＞
こんなんで解決するわけ無いわな～。
何事もそうだけど、コーダーとかデザイナーにありがちなとりあえず某魔王様のごとく「なんかいけそうな気がする！」で「よくわからない式 パッケージ」突っ込んでみる方法はよくないってことだね・・・。
その後、RustをVisual Studio Build Tools含めた依存関係を(レジストリとか環境変数とかも)全てクリーニングして、再度インストール。
今度はRustインストールの完了時点で先にパスを通してみたが、まったくもって解決せず・・・はてさてどうしたものか。
というわけで、原因を探ることにしてみた。
「error: linker `link.exe` not found」って言う文面通りに、単純に直訳で「link.exeが見つからない」って判断するのは早計なのかもしれない。
こういう場合、動かないこと自体に悩んでネットをまさぐって書かれた方法で環境を汚染しまくって無駄に調べる事柄を増やすより、「何が原因か」というところに焦点をおいて最低限動作するはずの環境でなぜ動かないかというところを探るべきである。
というわけで三度目のインストールを決行。
まず、今度はVisual Studio Build Toolsのインストールを先に行ってみた。
無論、このときにVisual Studio Build Toolsのレジストリ値や環境変数の動向にも注意する。
通常、Windowsのシステムでは再起動を一度でもしていない時点では、レジストリ値が追加されても依存して(させて)動作する他のプログラム上からは認識されない。
インストール後、再起動をすることで初めて認識されるものである。
再起動せずにRustをインストールする。
すると、やはり「error: linker `link.exe` not found」のエラーが発生し、この後に再起動をしても結果的には同じ。
ということは恐らくRustインストール時点で、Rust本体がVisual Studio Build Toolsのレジストリ値を見つけて参照しているため、認識できない状態ではそこらへんの連動がうまいこと取れないらしい。(ひょっとすると、Rustがインストールされる際にこの値を保持するために本体の設定ファイル等にVisual Studio Build Toolsのディレクトリ情報とかを書き込んでいるのかもしれない)
とすると、これって「link.exeが見つからない」じゃなくて「link.exeが認識できない」って意訳でも受け取れるんじゃないのか？？？
ならばと思い、もはやこの時点で完全に作業と化したクリーニングを行ってからの実に四度目のインストール。
今度はVisual Studio Build Toolsのインストール後に、こやつのレジストリの値を他のプログラムから参照できるようにするためにPCを一旦再起動。
で、再起動後にRustをインストールしてみる。
すると、Rustインストール後のメッセージが明らかに変わっていることに気がついた。
頑固な油汚れのようにしつこく表示されていた「Visual Studio Build Toolsがないとコンパイルできひんで」ってメッセージが消えているではないか！
Rustにパスを通すために環境変数を追加して、再びPCの再起動を行う。
cargo new –binを実行してプロジェクト作成、プロジェクト配下で恐る恐るcargo runを実行してみると・・・
やたぁぁぁぁぁぁあああ！
hello worldが表示されたあああああああ！！
・・・ふ、ふえぇぇぇんっっっっ！！！
併せて無事にhello.exeのファイルにもコンパイルされている。
やはり、入れたアタリは正しかったようだ。
別ドライブにRust関係を全て展開させるのであれば、レジストリの値を正常にRust本体が認識できるような形にしなくてはならないみたい。
これでうまく行っていなかったら、「キミは絶版だァァァァァ！！！」とか某仮面戦士のおじさんのように叫んでいなければやりきれなかっただろう。
現行、この方法で構築したRust環境は標準ライブラリや他クレートとかも特に過不足なく動き、Rustのチュートリアルも問題なく進められている。（少なくともcattlemuteの手元では・・・だけど）
あとは他のプログラミング言語と比較してもまるで宇宙語と呼ぶしかないRustでハテサテどこまで遊べるか、ってところの問題はあるけどね。
そもそも、hello worldを出すところで真っ先に躓いているわけだしなぁ～・・・
ともあれ、心の声ばかりが先行してまともなまとめ方できてないので、cattlemuteがやった手順を細かな所を追記してもう一度記載。
Rustを別ドライブに展開させる方法
- 何よりも先に必ずVisual Studio Build ToolsでC++のコンパイラをインストールする。(言語パックは「日本語」「英語」を選択)
インストール時に必要なファイルにダウンロードエラーが発生した場合は日を変えて再度インストール。
インストール先は任意のディレクトリ(同一ドライブ又は別ドライブどちらでも)でいい。 - Visual Studio Build Toolsをインストールし終えた時点で、一度PCを再起動してレジストリ値をRust本体から読み取れる状態にしておく。
- 再起動後、rust-init.exeをRust本体をインストールしたいディレクトリ(ドライブ任意)に配置して実行。
DOS窓の選択肢は通常のインストール(1のやつ)でOK。
このとき、Visual Studio Build Toolsがないと言われたらダメ。やり直し。 - インストールしたRust本体のファイル「.cargo」「.rustup」に対してパスを通す。(ユーザの環境変数でもシステム環境変数でもどっちでもいい)
「Path」変数 (既定 なければ作る)→Rustのインストールディレクトリ\.cargo\bin;
「CARGO_HOME」変数 (新規で作る)→Rustのインストールディレクトリ\.cargo;
「RUSTUP_HOME」変数 (新規で作る)→Rustのインストールディレクトリ\.rustup; - Rust本体のインストールとパス通しが完了したら、PCの再起動を行う。
- cmdより「cargo new プロジェクト名 –bin」でプロジェクトを配置したいディレクトリ下でコマンド実行。
- プロジェクトのディレクトリに移動して「cargo run」を実行してコンパイルが正常に行われることを確認する。
まぁ、そもそも別ドライブにインストールしないのであればここまで面倒なことしなくてもいいんやろうけど(´・ω・｀)
付け加えて最後に雑談がてら。
そもそも、久しぶりの投稿でなぜいきなりRustなのかっていうのは、通常の汎用端末とか組込系の専用端末とか問わずに使えるから、とりあえずやってみるかって実に安直な理由。
スクリプト系の言語ばかりが何かとピックアップされる近今はPC・タブレット・スマホに限っては大抵これでなんとかなるもんだけど、いざっていうときにコンパイルベースのきちんとした言語を使えれば何かと便利やしな～。
あと、どこまでを既成のフレームワークやAPIで作るのかってところが個人的に気にかかるのもある。
例えば、今こうしてcattlemuteが使っているCMSのWordPressも個人のブログだから自己責任の元でありがたく有用に使えているわけだけど、自分が過去やっていたようにサイト制作にOSSのCMSでお金をいただいて、さも当然のように大本の顧客に導入させるのってよくよく考えてみれば凄まじく恐ろしいことじゃない？
・・・だって、サイト制作時に作られるテーマはともかく、配布されているプラグインとかWordPress本体はなんの保証もないんだよ？？
例えば、制作時にプラグインを入れてもらっていたとしても、運用中にプラグインで起きたエラーとかって直してくれる制作会社さんなかなかいないやん？
というか、問題が発生したら別のプラグインにすげ替えて「提案」という「魔法の言葉」で片付けて煙に巻く会社さんなんてそれこそいくらでもある。
たとえフリーで配布されているプラグインであろうとも発生した問題とか事象であれば、使用することを決めた顧客管理サイド自身がきちんとそれを解析して問題解決まで一手に面倒見るべきなんだけどね。
それがフリー配布のツールを使う側の最低限の責任ってもんよ。
(顧客管理サイドが指定した外国で作られているであろうプラグインの導入を指示してきて、渋々入れたはいいがそのプラグインが日をおいてから案の定問題を発生させて、解析と修正をこちらにぶん投げられてプラグインそのものを渋々直したこともあったけど・・・よくよく考えればこれって悪い意味で正気の沙汰じゃないよなｗｗｗ)
そういえば、某接触管理アプリもいざ問題が発生したらAPIのせい、手の施しようがないので放置、メディアに取り上げられそうだからやむなく別の企業に解析を委託するというスリーアウトで前半一発コールドゲームな現状をみると思うところが止まらない。
結局、このAPIがOSSだったのか商用だったのかは知り得ないのでさておき（使い方を間違えたと報じられているあたりOSSなんかもしれんけど）、目的の基幹になる部分を全て外部のツールだけで賄うということがどれだけ恐ろしいことか。
プロジェクト管理・開発・サポート・リリースが予想外の多重芋づる式でなされていたのは流石に乾いた笑いが止まらなかったが・・・。
やっぱり基幹の部分はある程度自前で作らなあかんわな～。
顧客管理サイド自身が保守・改修をできないのであれば、そもそもそういったものを使うべきではない。
せめて主体とするサービスに使用するツールの基幹くらいは時間をかけてでも独自のものを作るべき。
無論、制作・開発会社を選ぶ顧客側も、きちんと「制作・開発会社の独自ツール」か「ありふれた一般ツール」の選択を提示できるところを見極めたほうが後々のトラブルを最低限に抑えられると思う。
「いい加減、そろそろ電子マネーを」とも思ってるけど、こうした事情で作られるのが常態化している国産のアプリは非常に危っかしいので絶対に使わないようにしようと思うこの頃(´・ω・｀)