Jamano's Blog 2nd gen.
折角の英語環境があるので、Msysでの構成にも挑戦してみましたが、豪快にMsys2の環境生成で失敗。なんとかのバージョンがとか、シグネチャがとか多数文句が出ます。
これは言語環境では無く、そもそも引っ張ってくるMsys2のバージョン違いが問題なんでしょうけど、別世界から引っ張ってるのでしょうかね。とても謎。いつも言っているように、元の開発者グループがどうやってパッケージを生成しているのか本当にわかりません。
5.1.12についてはこれで一段落かな。次はLinux側で作業しますか。それ以前にLinux環境を再構築しなくてはならないので、少し面倒だな。
vcpkgの作成で結局7時間ほどがかかりました。その後のビルド作業中にglewとdoxygenが無いと苦情が出たので都度追加。結局このビルドの為にインストールしたのは、
Visual Studio2019の機能としてcmakeとgitは含まれている感じなので、あえてインストールしておく必要は無かったかもしれませんが、vcpkgやKicadのソースの取り出しに使用したので、VSとは別に入れておいた方が良い気がします。
さて、警告は多数出たのですが、Build自体は2.5時間ほどで無事終了です。本体より環境構築の方が時間がかかっているのは癪なんですけどね。
相変わらずインストール用パッケージが生成されていないのは謎というか、反省点なのですが、まぁ需要が全くない自己満足ビルドなのでこれでOKかな。と言いたいところですが、元がWinbuilderと言っている以上インスートラーパッケージまで生成してくれないと不満が残ります。ビルドログに何か残っているかもしれませんね。
さて次はVM上の英語版Windowsではなく、英語環境として追加したユーザーアカウントで試したら何が起きるのかを確かめないと。
MSの開発用ライブラリから期間限定使用のWindows11の環境をダウンロード。VMplayerをインストールしてさっそく使用開始。
起動した画面はあちこちにあるサンプル通りの画像です。(左上になんか出てますが、そこはご愛敬ってことで)
開発テスト用ってことで最初からVS2019が入っているので、必要なのはcmakeなどのCLI系C++の開発ツール群をVSに追加してやるだけです。後はgitを入れて、PATHを通し、vcpkgのclone化と使用開始手順。次に環境変数VCPKG_DEFAULT_TRIPLETにx86-windowsをセットして、.\vcpkg install boost cairo curl glew gettext glm icu libxslt ngspice opencascade opengl openssl python3 wxpython wxwidgets zlib
を書いてある通りに実行。流石にVM上なので結構時間がかかります。と言うか5時間経過してますが、まだこの手順が終了しません。しかしこちらの環境だとエラーになることもなく進行しているので、やはり元から英語環境でないとダメなんですね。
ちなみに日本語環境下でcp1251やcp65001を試してみましたが、同じエラーが出ますので、一時的対処ではダメなようですね。何か他の環境変数による指定が効いているのかもしれませんが、ぱっと見では見当たらない。
気になったので少し調べてみたら、ユーザー毎に言語系を変えられるようです。だとすれば英語系を使用する新しいユーザーアカウントを作ってそっちで作業すれば良かっただけのことだったかもしれません。後で試してみますか。
まぁ、Windows11に触れたのでとりあえず良しということですね。さて181/184で停滞しているvcpkgの処理。早く終わらないかな。
PCの再調整が終わったので、再度rebuildに挑戦。
本家を見ていたら「これからはWindowsの場合はMSVCだぜ!」ってな表記があったのでVSを入れて段取り開始。
VSのような便利なシステムをフルで無償利用させてくれるMSの太腹に感謝です。
vcpkgの構成の途中でwxpythonの構成でerror停止。msys2利用でも問題になるのですが、vcpkgでもエラー!
内容は構成の途中で文字コード変換からみでエラーになることが分かりました。なら対処法はと探ってみるとwxpythonのフォーラムで「よくわからないので、対処無し」と7月に書き込まれて放置状態。たぶん文字コード変換の必要のない環境では発生しない問題なのでしょう。
かくなる上は文字コードを英語に変更して試す必要があるのですが、これだけの為に再インストールは辛いな。普段使いにも不便になるし。
というわけでテスト用のWindows10イメージがマイクロソフトから提供されているので、VMに食わせて再挑戦してみますか。
もともとの始まりはうっかり「復元パーテーション」を消してしまったことから始まっているのですが、なんだかんだで完全クリーンインストールとなったのでだいぶ動きが軽快になりました。
このPCは当初Wind0ws8でしたが、無料アップグレードのおかけで8->8.1-10と来て、Windows10の各種エディションを経由して20H1までアップグレードで来ていたのでした。
また途中であれこれインストールしたりアンインストールしたりで結構なゴミが溜まっていたのでしょう。
近頃のアプリケーションやドライバーは更新確認を言い訳としてやたらに常駐部を残してくれるのでシステムとしては無駄が多くなります。なので、その手のソフト(Abodeとかアドビとか…)を入れなければだいぶ動作が軽快になりますね。更新確認なら起動時に一発だけで良いと思うのですが、少なくないソフトが常駐部を残してくれるのでシステムメモリーを汚します。
常駐しているからには更新確認以外に動作状況の確認やら競合ソフトの状況なんかを開発元に送信しているのではないかと疑ってしまい、できるだけインストールしたくない状況となります。これは開発元としてもあまりよい状況では無いと思うのですがどうなんでょうね。
自宅に持ち帰ったPCの調子が良くありません。謎のプチフリーズが多発するし、他にもなにか不安定。まぁ、HDD-SSD(A社)-HDD-SSD(B社)とイメージコピーで来ているので、構成的に無理が発生しているのかも。
なので思い切って再インストールすることにします。まぁいまだとPCの中身もだいぶ減っているのでバックアップも楽だしね。
11/18 追記
クリーンインストール自体はさほど時間もかからずに終了。しかしライセンス認証のためにMSのアカウントと紐づけした時にDesktopやMyDocumnetなどがOneDirve上のフォルダー設定にされてしまい、解除できない。(移動できないフォルダーがあるとかなんとか)
旧のデーターはまだ残したままなので、今晩にでも再インストールしなくちゃ。
それにしても、どこでそんな設定になったのやら。お節介で迷惑な仕様だ。
コメント欄で新しい版が出ていることを教えていただきました。ようやく自宅PC環境が(windowsだけだけど)整ったので、さっそく作業開始。
ところが、コメントをくださった方と同じようにMsys2がメタメタ。パッケージのアップデートができない状況です。なので、こちらもMsys2をそっくり入れ替え。
あれこれ用事が有るので、今日はここまでかなぁ。
ある程度make_all.batが走るところまでは行きたいな。
22:20追記
やはりwxPythonからみのエラーが出たので、無効化して再実行。ソースがいつのまにか5.1.12になっていて驚きますが、さらには
なんてエラーが出て停止。本当に開発チームは提供されているkicad-winbuilderでスムーズにインストーラーパッケージが生成できているのだろうか?
新しい版が出たようなので久しぶりにPKGBUILD。いつものように関係ファイルを用意して作業開始。
しかし、いつものようにエラー多発で散々でした。
まず最初のトライアルではmsys2の何かのプロセスが暴走してしまったようで何をやってもエラーとなる上に復旧しなくなりました。仕方がないのでWindowsの再起動からやりなおし。
2回目の試行ではuctr64が無いと怒られます。msys2_shell.cmdを実行して端末画面を出して、pacman -Syとすることでこれは解決するらしいので試してみると確かに解決します。これだったら最初から(初回のPKGBUILD実行時に)解決しておいてほしいな。
さらに3回目の試行では今度はclang64のmirrorlistが無いとか。環境整備はこっちの知ったことではないんだがと思いつつも、解決しないと先に進めませんのでmsys64/etc/pacman.d/にあるmirrorlist.ucrt64をコピーしてmirrorlist.clang64にrename。さらに中身の/ucrt64を全部/clang64に書き換えて再試行。
4回目ではclang64のdatabaseが無いと怒られます。再度pacman -Syを実行することで作成はされるんですが、2回目の時に実行したpacman -Syで作成されなかったのはなんでかな… つくづく底意地の悪い仕様ですね。
ここまでやってようやく環境が整ったようでbuild作業が始まります。しかし最後の最後で今度は、
==> パッケージを作成 "mingw-w64-x86_64-kicad-git"... -> .PKGINFO ファイルを生成... -> .BUILDINFO ファイルを生成... -> .MTREE ファイルを生成... -> パッケージの圧縮... ==> 作成完了: mingw-w64-x86_64-kicad-git r22369.a8672dd2f9-1 (2021年05月05日 16時07分57秒) => WARNING: You don't have the required toolchain installed for mingw32. => WARNING: To install it run: 'pacman -S mingw-w64-i686-toolchain' ==> エラー: Cannot find the strip binary required for object file stripping.
と言う訳でtoolchainを導入せよとのことなので、pacmanから実行。そういえば5.1.9の時もそんなエラーが出ていたなと思い出しましたが、進歩が無いですね…
それよりも r22369.a8672dd2f9って何だよと言う訳で再度PKGBUILDの中身をチェック。例によってノーマークの場合はnightly-buildとなる模様です。
これだとなんかねと言う訳で再度ディレクトリ内を探してPKGBUILD-STABLE-5.1が5.1.10のためのファイルであることを確認したのでこれをPKGBUILDにrenameして再度トライ。
今度はソースパッケージをgit cloneした後のMD5SUMチェックで引っ掛かります。さすがに腹が立ったので全部のMD5SUMチェックを’SKIP’に変更してチェックしないようにして再実行。ようやく最後まで進行してパッケージが生成されました。
しかし、出来上がったのはmsysへのインストールパッケージである.zstファイル。必要なのはWindows用のインストーラーパッケージなので、まだ完了ではありません。
よくよく画面を見ると、
==> 作成完了: mingw-w64-i686-kicad-git 5.1.10_1-1 (2021年05月06日 08時49分54秒) -- Success 0: cd "C:/kicad-src/msys64/home/Owner/MINGW-packages/mingw-w64-kicad-git" && export CARCH=x86_64 && TERM=vt220 makepkg-mingw -s --noconfirm CMake Error at KiCad-Winbuilder.cmake:346 (message): Unable to extract major and minor version string
となっていて、まだ何かエラーがある模様。情報が少なすぎでどこをどうしたらよいのやら… まぁもう少しだな、週末頑張ろう。
あれやこれやで惰性でボーっと過ごしていたら、Fedora34リリースの発表がありました。ちょうど休日だったので、これ幸いと更新作業開始。
Release NoteにあるUpgrade手順に従って問題なく終了です。32->33の時はいくつかのパッケージで問題が起きましたが、今回はそんなこともの無く至ってスムーズに進行していささか拍子抜け。時間はかかった様ですが、途中出かけていたので実際に要した時間は分かりません。
さて新しいシステムになって何が変わったのか相変わらずよくわかっていません。Xのベースが変わったとの話ですが、劇的にパフォーマンスが向上したと言う訳でもないので使っていてもよくわからないなぁと。
画面左下の電源OFF等のガジェットの出方が変わったのが、現在のところの気づきかな。
例によってReleaseと同時にUpdateパッケージが出ていますが、各FTPサイトの更新が間に合っていないようで、どこに行ってもsrpmが取り出せません。1日待てばmirror化が行きわたるかな。まぁ焦ってどうこうってことでは全くないのでゆっくりやっていきましょう。ちょうど連休期間に入ることだし。
とりあえず途中経過。今回はビルドの途中でコンパイルエラーになってしまい。最後まで行きません。
何だろうな… VCPKGではうまく行っているので納得が行かない。wx云々って出ていたので、そのへんの何かのバージョンがVCPKGでやった時と違っているのかも。
それにしてもニトログリセリン並に繊細過ぎる…