Insider で Windows 10 19041.1 に update して WSL2 に Arch 環境を作り直したメモ ( 昨夜まで WSL1/Ubuntu を使っていました )

↑ WSL2 で Arch linux が動いていて Windows Terminal (Preview) から使える様子。

手順メモ:

1. Windows 10 19041.1 (執筆時点) 以降のバージョンへアップデートする (執筆時点ではまだ Windows Insider の登録と設定が必要。説明略 -> https://insider.windows.com/ )
2. WSL2 を使用可能、標準に設定 ( https://docs.microsoft.com/windows/wsl/wsl2-install )
   • Tips: dism.exe は管理者権限で実行する必要がある。 sudo とか choco してないとめんどくさいかも
   • Tips: dism.exe の実行例をそのまま実行すると dism.exe は処理を返さないので、いつまでもコマンドの処理が終わるのを待つ必要はなかった
   • Tips: sudo dism ... を2つ実行したら処理が返ってこなかろうが、 restart する…のだけど、念のため手作業で可能な限り動作中のアプリを終了させてから restart した方が安全。
     • 私はなぜか TaskManager が終了できないけど強制的に終わらす？とか出て、状況確認＆手動で終わらせようとNoしたら…Noしたのに…なぜか更新しています画面に遷移してエターナル更新終わらない状態に突入されました。その後、PCをメインボードレベルからリセットしてやり直しました。
   • Tips: wsl --set-default-version 2 が期待動作すれば、そこでWSL2準備は完了です
3. https://wiki.archlinux.jp/index.php/WSL_%E3%81%AB%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB を読んで「めんどくさいな」とか「Archのビルドマシーン必要なのか」とか少し不安を覚えます。覚えるだけでいいです。
4. https://github.com/yuk7/ArchWSL/ を発見して「ありがとう♡」と思いつつも一応 Arch には Windows Store 事件もあったのでそれとなく中身には気を付けつつ使わせて頂きます。
   • https://github.com/yuk7/ArchWSL/blob/master/README.ja.md#%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB など読んで zip か appx+cer どちらでインストールしたいかを考え、選び、配置して実行すると初回実行時に Windows の wsl コマンドでも扱える状態に register されます。同時に、WSL2 の設定を標準化していれば、 rootfs.tar.gz から自動的に ext4.vhdx が生えます。
   • https://github.com/yuk7/ArchWSL/wiki/How-to-Setup を見ながら、 WSL2/Arch の初期状態を整えます。
     • pacman -Syu の前に、 pacman-key --init と pacman-key --populate 、それから pacman -S archlinux-keyring がたぶん必要です。
5. おまけ: Windows Terminal の設定で標準で起動するタブを Arch あるいは他の何かに変えたい場合は
   • profiles.json に globals.defaultProfile を追加して、値に profiles[n].guid の文字列値と同じ値を設定します。( n は出したいのプロファイルのものを目grepして探してください )

vscode extension: 開かれている vscode.TextEditor を列挙する方法のメモ

import * as vscode from 'vscode'

// 列挙した TextEditor を格納する array
const es: vscode.TextEditor[] = []

// 次の TextEditor を取得するトリック
let nextTextEditor = async () =>
{
  await vscode.commands.executeCommand( 'workbench.action.nextEditor' )
  return vscode.window.activeTextEditor
}

// 現在の TextEditor から逐次 TextEditor を取得し、 undefined または既に列挙済みの TextEditor が再列挙されたらおしまい
// 2020-01-05T15:41+09:00 修正(†1)
for ( let e = vscode.window.activeTextEditor; e && !es.some( _ => (<any>_)._id === (<any>e)._id ); e = await nextTextEditor() )
{
  // おまけデバッグコード: 直前に取得された TextEditor に紐づいている TextDocument の uri をロギング
  console.log( 'debug', e.document.uri )
  es.push( e )
}

参考リンクを元にTS初心者が書いてみました。バッドノウハウの香りが漂う気もしますが、いまのところ vscode の extension 用に公開されている API で実装する方法はこんな具合にならざるを得ないようです。

特定の状態の TextEditor を見つけたいだけなら for の中で見つけたら break 、全部の情報が欲しいなら列挙を終えてから es を観察、操作する実装を応用すればよいでしょう（たぶん）。

参考

• https://github.com/Microsoft/vscode/issues/65825
• https://github.com/microsoft/vscode/issues/15178#issuecomment-283072868
• https://github.com/eamodio/vscode-restore-editors/blob/9e9b972ca2cb8949a747ddbae101b075e2713f1b/src/documentManager.ts#L54
• https://github.com/eamodio/vscode-restore-editors/blob/2ac2f865201cdb67fd531cd06bdbb082d330ccac/src/activeEditorTracker.ts

(†1) 修正

// 修正後
for ( let e = vscode.window.activeTextEditor; e && !es.some( _ => (<any>_)._id === (<any>e)._id ); e = await nextTextEditor() )

// 修正前
for ( let e = vscode.window.activeTextEditor; e && !es.includes( e ); e = await nextTextEditor() )

TSを介してもESはやっぱりこわいです。疲弊します。おうちに帰りたい的な気持ちになりました…。（個人のTS初心者の感想です）

nodejs: child_process.spawn とシェル実行の方法の模範解答についてのメモ（あるいはバッドノウハウを広めないための自分用の戒めとしてのメモというかあけおめ生存報告のメモ）

最初に答え

let spawn = require('child_process').spawn;

// 模範解答（たぶん）
let p = spawn( 'echo', [ 'hoge' ], { 'shell': true } );

p.stdout.on( 'data', payload => console.log( `[spawn/stdout]: ${payload.toString().trim()}` ) )
p.stderr.on( 'data', payload => console.log( `[spawn/stderr]: ${payload.toString().trim()}` ) )
p.on( 'exit', exit_code => console.log( `[spawn/exit] ${exit_code}` ) )

参考

• https://nodejs.org/api/child_process.htmlhttps://nodejs.org/api/child_process.html#child_process_child_process_spawn_command_args_options

要点

• spawn には第3仮引数の options というのがあります
• options の shell を定義すると、
  • true にすると実行環境に応じて、 Windows なら process.env.ComSpec から実質的には cmd 、 nodejs が UNIX として扱う環境では /bin/sh に -c オプションを噛ませたシェル実行モードになります
  • false にするとシェルを介さずに spawn の第1仮引数の command を直接実行します
  • string 型の値を与えると、与えられた文字列をシェルコマンドと見做して、それに -c オプションを噛ませたシェル実行モードになります

例えば、 powershell をシェルとして実行したい場合は↓のようになります。

let spawn = require('child_process').spawn;

let p = spawn( 'Get-ChildItem', [ '..' ], { 'shell': 'powershell' } );
p.stdout.on( 'data', payload => console.log( `[spawn/stdout]: ${payload.toString().trim()}` ) )
p.stderr.on( 'data', payload => console.log( `[spawn/stderr]: ${payload.toString().trim()}` ) )
p.on( 'exit', exit_code => console.log( `[spawn/exit] ${exit_code}` ) )

powershell は通常は Windows 環境のシステム標準で PATH が通り、 PATHEXT に .EXE があり NTFS は case-insensitive なので、実行ファイルのフルパスを書かなくても powershell だけで実行でき、かつ -c オプションが期待動作するのでこれで使えます。

おまけ

諸事情により7年ぶりに TypeScript でおもちゃを書きはじめました。それで、なんでわざわざこんなメモを残したのかというと、世の中にはしばしば公式ドキュメントを読めばきれいな実現方法が書いてあるのに、読まずに、"俺は試行錯誤の結果こうしたらできたからみんなもこうするといいよ"的な野良バッドノウハウがおそらく誰も悪意などなく意図せずとも広まりやすい言語というのがあります。それ自体は発生してしまったものですし、わざわざあちこちに公開されているバッドノウハウへたまたま見つけたからというだけで7年ぶりにちょっと触った程度の nodejs 初心者がマサカリを投げるほど、私は傲慢でも暇でも親切でもないのですが、自分用には面白い戒めにもなるな、と思い、少し丁寧にメモを残してみました。

// これは日本語に限らず、参考用にソースを眺めたOSSでも少なくなかったバッドノウハウの例です
let p = spawn( 'cmd', [ '/c', 'echo', 'this is a bad know-how; read the official document first.' ] )

私もたくさんのバッドノウハウを悪意はなくとも広めてしまっている事もあるのでしょうが、なかのひとの気持ちとしてはできるだけきれいに、かつ（複数の意味で）面倒なく快適に、これからもお鮨を食べ、フリッツを食べ、不幸よりも幸せを多く感じて2020年以降も生きたいと思います。

あけおめ。

vcpkg_chii: vcpkg cmake hyper integration injector 作りましたのメモ

↓つくりました:

• https://github.com/usagi/vcpkg_chii ; vcpkg_chii: vcpkg cmake hyper integration injector
  • vcpkg_chii ( vcpkg cmake hyper integration injector ) is a CMake module for vcpkg hyper integration for CMake
    • vcpkg ( Windows, GNU/Linux, OSX 向けのクロスプラットフォーム C++ パッケージマネージャー)
    • CMake ( クロスプラットフォームの C++ プロジェクトではデファクトスタンダードの1つのメタビルドツール )

vcpkg を使い始めてから、自分の便利用に書いた CMake 用のギミックをモジュール化したものです。 README.md の冒頭で

Let's do more easy, make it more convenient for vcpkg and CMake users.

(にほんご↓)

もっと楽に、便利に、 vcpkg と CMake ユーザーを。

と、いうわけで vcpkg_chii を使うと、 "hyper" (過剰なくらいの) な vcpkg のインテグレーション(統合機能)を CMake へ注入します。具体的には、

1. cmake .. するだけ(理想的には)でOKになります(†1)
   1. VCPKG_TARGET_TRIPLET は環境変数またはシステム標準から自動設定されるようになります
   2. CMAKE_TOOLCHAIN_FILE は vcpkg コマンドのパスから自動設定されるようになります
2. 事前に vcpkg install <library> することを気にしなくてよくなります
   1. 必要なライブラリーは cmake の中で自動的に vcpkg でインストールされるようになります

なので、ちょっと過剰なんですが、実用性としてはとても便利になるのでまあいっかーと思います。注意点として、一応、この機能を使用するプロジェクトを公開する場合は、ソースからビルドするユーザーに対してこんな機能を取り込んでいるよって表示はした方が良いと思います。何も指定しないと試しに CMake したら依存ライブラリーを vcpkg で全自動で落としてビルドし始めて気づいたら cmake するだけでビルドまで終わってしまった…というのは、状況によっては望まないか警戒されると思うので。たいていは、実際問題便利なだけだと…思うけどね。

ちなみに、 cmake .. -DVCPKG_CHII_ENABLE=OFF すれば vcpkg_chii の機能は使わないモードになるので、 vcpkg あるいは vcpkg_chii を使いたくない状況やユーザーにも必要最小限ていどには安心かもしれません。

vcpkg, cmake に興味があれば、とりあえず使ってみて下さい。使い方の例は、 example に簡単な vcpkg から Eigen と google-test を引っ張ってきて使う CMake + vcpkg_chii 採用なミニ・プロジェクトを用意したので、そちらでお試し下さい。

(†1): vcpkg 標準の CMake インテグレーションは cmake .. -DCMAKE_TOOLCHAIN_FILE=<path-to-vcpkg>/scripts/buildsystems/vcpkg.cmake -DVCPKG_TARGET_TRIPLET=x64-windows-static とか良くも悪くも cmake するときに長い呪文の詠唱を必要とします。

C++ のパッケージマネージャーの選択メモ( conan vs. vcpkg vs. Hunter on Windows and Ubuntu ): C++ 実装がサブプロジェクトとして内包されるクロスプラットフォームアプリのリポジトリーの場合

タイトルが少しややこしいので最初に整理します。

• このメモは: C++ のパッケージマネージャーの選択のはなし
• ただし:
  • アプリはクロスプラットフォーム ( このメモでの具体例は Windows-10 & Ubuntu-19.04 )
  • アプリ全体(=このメモでは「ソリューション」とします)はいくつかの構成部品(=このメモでは「プロジェクト」とします)に分けて作られる
  • プロジェクトの1つ以上に C++ を採用したい
    • そのプロジェクト単位で C++ のライブラリーを管理できるパッケージマネージャーを導入したい → どうするのが楽そうかな

のメモです。

選択肢と大雑把な検討

1. conan https://conan.io/
   • クロスプラットフォーム対応の C++ のパッケージマネージャーが欲しいの悩みに答えてくれる定番。 CMake でごにょごにょする
2. vcpkg https://github.com/microsoft/vcpkg
   • Microsoft が Windows 向けの Visual Studio のために作ったパッケージマネージャー「だった」。今では GNU/Linux と OSX も対象プラットフォームという事になっている
3. Hunter https://github.com/cpp-pm/hunter
   • conan よりキレイに CMake でごにょごにょしてくれるらしいクロスプラットフォーム対応の C++ パッケージマネージャー
4. (最終手段) ライブラリーごとに手書きの CMake 魔術を作りプロジェクトの CMakeLists.txt へ仕込む https://cmake.org/cmake/help/latest/
   • これを選択すると保守の手間が増えるので 1, 2, 3 の何れかにしたい

対応パッケージの手広さ対決

登録パッケージ数を比べてもあんまり意味が無いので、実際に私がソフトウェア開発プロジェクトで触れる機会、可能性のあるライブラリーやフレームワークを適当に列挙して、実際にコマンドで search を叩く、最新のリストから grep しつつ、ついでにライセンスとオリジナルの入手情報も整理しました。パッケージ名に気を付けると良さそうな場合は有無の〇×の〇代わりにパッケージ名を記載しました。

要注意 この表は 2019年12月29日 の調査結果です。

category	name	LICENSE	conan	vcpkg	Hunter	original
3D-data, Format	Assimp	BSD-3-Clause	×	〇	〇	https://github.com/assimp/assimp
All-purpose	Boost 1.0	Boost 1.0	〇	〇	〇	https://github.com/Boost 1.0org/Boost 1.0
Civil-engineering	OSGeo/PROJ	MIT	×	proj4	PROJ4	https://github.com/OSGeo/PROJ
Civil-engineering, Image, Format	OSGeo/libgeotiff	public domain	×	〇	×	https://github.com/OSGeo/libgeotiff
Compression	zlib	zlib/libpng	〇	〇	〇	https://www.zlib.net/
Compression	zstd	BSD | GPLv2	〇	〇	×	https://facebook.github.io/zstd/
Compression	liblzma	public domain	〇	〇	lzma	https://tukaani.org/xz/
Compression	Snappy	Apache 2.0	〇	〇	〇	https://google.github.io/snappy/
Compression	LZ4	BSD-2-Clause	〇	〇	〇	https://github.com/lz4/lz4
Concurrency	OpenCL	Khronos OpenCL	〇	〇	〇	https://github.com/KhronosGroup/OpenCL-Headers
Concurrency	OpenCL-cpp	Khronos OpenCL	khronos-opencl-clhpp	×	〇	https://github.com/KhronosGroup/libclcxx
Concurrency	TBB	Apache 2.0	〇	〇	×	https://github.com/intel/tbb
Crypto	CryptoPP	Boost 1.0	〇	〇	〇	https://github.com/weidai11/cryptopp
Database	SQLite3	public domain	〇	〇	〇	https://sqlite.org/src/timeline
Database	sqlitecpp	MIT	〇	〇	×	https://github.com/SRombauts/SQLiteCpp
Image, Computer-visioning	OpenCV	BSD-3-Clause	〇	〇	〇	https://github.com/opencv/opencv
Image, Computer-visioning	OpenMVG	MPL 2.0	×	〇	×	https://github.com/openMVG/openMVG
Image, Computer-visioning	OpenMVS	AGPL	×	〇	×	https://github.com/cdcseacave/openMVS
Image, Font, Format(*)	stb	public domain	〇	〇	〇	https://github.com/nothings/stb
Image, Format	libtiff	BSD-like	〇	tiff	tiff	http://www.simplesystems.org/libtiff/
Image, Format, JPEG	libjpeg	BSD-like	〇	〇	jpeg	http://libjpeg.sourceforge.net/
Image, Format, PNG	libpng	zlib/libpng	〇	〇	png	https://libpng.sourceforge.io/
Image, Format, WebP	WebP	BSD	〇	〇	〇	https://developers.google.com/speed/webp/
Linear-algebra, Math	Eigen	MPL 2.0	〇	〇	〇	http://eigen.tuxfamily.org/
Networking	curl	MIT	〇	〇	〇	https://github.com/curl/curl
Networking	curlpp	MIT	×	〇	×	https://github.com/jpbarrette/curlpp
Networking	BoringSSL	OpenSSL	×	×	〇	https://boringssl.googlesource.com/boringssl/
Networking	OpenSSL	Apache-style	〇	〇	〇	https://www.openssl.org/
Networking	Crow	BSD-3-Clause	×	〇	×	https://github.com/ipkn/crow
Networking, RPC, gRPC	gRPC	Apache 2.0	×	〇	〇	https://github.com/grpc/grpc/tree/master/src/cpp
OpenGL	OpenGL Registry	Khronos OpenGL	×	opengl-registry	×	https://github.com/KhronosGroup/OpenGL-Registry
OpenGL	GLFW	zlib/libpng	〇	glfw3	〇	https://github.com/glfw/glfw
OpenGL, GUI	imgui	MIT	〇	〇	〇	https://github.com/ocornut/imgui
OpenGL, Math	glm	Happy Bunny	〇	〇	〇	https://glm.g-truc.net/
OpenGL, Windows	glew	BSD-3-Clause	〇	〇	〇	https://github.com/nigels-com/glew
OpenGL, Windows, Direct3D	ANGLE	BSD-3-Clause	×	〇	×	http://angleproject.org/
Script, Javascript	V8	BSD-3-Clause	×	×	〇	https://v8.dev/
Script, Lua	Lua	MIT	×	〇	〇	https://github.com/lua/lua
Serialization	cereal	BSD-3-Clause	〇	〇	〇	https://github.com/USCiLab/cereal
Serialization, CSV	csv-parser-plusplus	GPLv3	×	×	〇	https://github.com/headupinclouds/csv-parser-cplusplus
Serialization, CSV	fast-cpp-csv-parser	BSD-3-Clause	×	〇	×	https://github.com/ben-strasser/fast-cpp-csv-parser
Serialization, JSON	RapidJSON	BSD-3-Clause	〇	〇	〇	https://github.com/Tencent/rapidjson/
Serialization, JSON, BSON	json	MIT	nlohmann_json	nlohmann-json	nlohmann_json	https://github.com/nlohmann/json
Serialization, MessagePack	msgpack	Boost 1.0	〇	〇	〇	https://github.com/msgpack/msgpack-c
Serialization, XML	RapidXML	Boost 1.0	〇	〇	〇	http://rapidxml.sourceforge.net/
Serialization, XML	Xerces	Apache 2.0	〇	〇	×	http://xerces.apache.org/xerces-c/
Unit-test	Catch	Boost 1.0	〇	〇	〇	https://github.com/catchorg/Catch2
Image, Computer-visioning	pcl	BSD-3-Clause	×	〇	×	https://github.com/PointCloudLibrary/pcl
Image, Computer-visioning	OpenNI2	Apache 2.0	×	〇	×	https://github.com/occipital/openni2
Concurrency, GPGPU	CUDA	GPLv2 and etc.	×	〇	×	https://developer.nvidia.com/cuda-zone

この調査結果からは、私の中では意外な事に vcpkg がとても有用そうな事がわかりました。少なくとも Windows で cl.exe 系のツールチェインを使う場合には vcpkg が期待動作しない事も少ないでしょうから、クロスプラットフォーム対応ではなく Windows だけを対象にする場合は vcpkg 一択で良さそうです。

vcpkg の懸念は Windows 以外でも期待動作してくれるのか…です。これは実際に試してみないと安心できません。

お試し

このメモでは...

1. Eigen http://eigen.tuxfamily.org/ と
   • // header only
2. Message Pack (msgpack-c) https://github.com/msgpack/msgpack-c を
   • // build required

conan, vcpkg, Hunter で取り込んでみます。

翻訳するソース my_something.cpp は...

#include <Eigen/Core>
#include <msgpack.hpp>
#include <fstream>

extern "C" double my_norm( double x, double y, double z )
{
  return ::Eigen::Vector3d{ x, y, z };
}

extern "C" void my_serialize( const std::string& path, double value )
{
  ::msgpack::sbuffer b;
  ::msgpack::pack( b, value );
  ::std::oftream( path, ::std::ios::binary ).write( b.data(), b.size() );
}

無事に build.cmake/lib/libmy_something.so を作れた場合は、 python と od (Ubuntuなどの場合) または Format-Hex (Windows/PowerShellの場合) で簡易動作確認します:

>>> from ctypes import *
>>> l = cdll.LoadLibrary( 'lib/libmy_something.so' )
>>> l.my_norm.restype = c_double
>>> l.my_norm( c_double( 1 ), c_double( 2 ), c_double( 3 ) )
3.7416573867739413
>>> l.my_serialize( c_char_p( 'out'.encode( 'utf-8' ) ), c_double( l.my_norm( c_double(1), c_double(2), c_double(3) ) ) )
0
(CTRL+D)

od -tx1z -Ax out または Format-Hex -Path out で out を確認

000000 cb 40 0d ee ea 11 68 3f 49                       >.@....h?I<
000009

Notes:

• 3次元ベクター { 1, 2, 3 } のノルムは 3.74165738677... くらいのスカラーです。 https://www.google.com/search?q=sqrt(1*1%2B2*2%2B3*3)
• msgpack の double 値のシリアライズ結果は 0xcb で始まり IEEE754/Binary64 の Big-endian 形式になります。 https://github.com/msgpack/msgpack/blob/master/spec.md#float-format-family

conan

導入方法

1. python と pip を使える状態にする
2. pip install conan

プロジェクトへのパッケージ追加方法

1. パッケージを探す:
   1. conan search "*eigen*" --remote=conan-center
   2. conan search "*msgpack*" --remote=conan-center
   3. コツ: 検索キーワードは小文字にし、ありそうな名称の前後に * を付けてワイルドカード付きで検索すると見つけやすいです
   4. 動作はわりともっさりですが、数秒待っていれば動きます
2. パッケージを確認:
   1. conan inspect eigen/3.3.7
   2. conan inspect msgpack/3.2.0@bincrafters/stable
3. パッケージを使用可能な状態にする:
   1. プロジェクト内のパッケージの定義ファイルを作る: conanfile.txt (†1)
   2. パッケージのビルドディレクトリーを作って入る: mkdir build.conan && pushd build.conan
   3. 導入: conan install .. && popd; .. は conanfile.txt のある場所
      • conanfile.txt へライブラリーを追加する事があれば conan install の再実行も必要
      • Windows, Ubuntu あたりの一般的なツールチェインはバイナリーが降ってくるのですぐ終わります
4. プロジェクトに CMake プロジェクトファイルを用意して conan のパッケージを使用してビルド:
   1. CMakeLists.txt を用意して conan 用の追記...
      1. include(${PROJECT_SOURCE_DIR}/conan.build/conanbuildinfo.cmake)
      2. conan_basic_setup()
      3. target_link_libraries( my_project ${CONAN_LIBS} )
   2. mkdir build.cmake && pushd build.cmake
   3. cmake ..
   4. cmake --build .

(†1) ↓ conanfile.txt; パッケージ名は大文字小文字に敏感です

[requires]
eigen/3.3.7
msgpack/3.2.0@bincrafters/stable

[generators]
cmake

パッケージの実体

• ~/.conan ディレクトリー内にパッケージごとに実体が conan install .. で必要になる度に導入が確認され格納される
  • プロジェクト内にはパッケージはソース、バイナリー何れも配置されず、 cmake から↑が参照される
  • パッケージの管理単位にバージョン情報なども内包しているので、複数プロジェクトでパッケージが混乱する事は無さそう(たぶん)

vcpkg

導入方法

1. git clone https://github.com/Microsoft/vcpkg.git
   • または git subtree, git submodule で取り込む
2. pushd vcpkg
3. vcpkg の実行ファイルをビルド; 数分程度かかるかもしれません
   • GNU/Linux っぽい環境: ./bootstrap-vcpkg.sh
   • Windows っぽい環境: ./bootstrap-vcpkg.bat
4. ビルドツールへの仕込み; しなくてもいいけど、すると便利かもしれないし、厄介事の原因になるかもしれないのでプロジェクトにあわせてどうぞ
   • CMake: cmake 叩く段階で -D すればいいのでこの段階では何もしなくてOK
   • Visual Studio: ./vcpkg integrate project または ./vcpkg integrate install https://docs.microsoft.com/en-us/cpp/build/vcpkg?view=vs-2019#integrate-with-visual-studio-windows
   • その他: 必要に応じて vcpkg 導入先の installed, packages あたりを眺めれば手インテグレートできそう
5. popd

プロジェクトへのパッケージ追加方法

Note: vcpkg をどこに置くかによらずパスを通したり alias を張ったりする場合は vcpkg/vcpkg とパス付きで呼ぶ必要はないのですが、今回はプロジェクト単位でライブラリー管理時にしか使わないので、パス付きで呼んで済ませます。

1. パッケージを探す:
   1. vcpkg/vcpkg search eigen -> eigen3 3.3.7-3 C++ template library for linear algebra: matrices, vectors, numerical solvers,...
   2. vcpkg/vcpkg search msgpack -> msgpack 3.2.0-1 MessagePack is an efficient binary serialization format, which lets you exchan...
2. バージョンの固定が必要なら ports ディレクトリーの中身を適当に編集して対処します
   • 不要な場合は何もせず↓へ
3. パッケージを導入:
   1. vcpkg/vcpkg install eigen3 終了時に CMake 用の情報を教えてくれます(†1)
   2. vcpkg/vcpkg install msgpack 終了時に CMake 用の情報を教えてくれます(†2)
4. CMakeLists.txt にライブラリーを追加; ↑で教えてくれる例をもとにプロジェクト名を main から実際の my_something へ変えて追加
   1. find_package( Eigen3 CONFIG REQUIRED )
   2. find_package( msgpack CONFIG REQUIRED )
   3. target_link_libraries( my_something PRIVATE Eigen3::Eigen msgpackc msgpackc-cxx msgpackc-static)
5. ビルド:
   1. mkdir build
   2. cd build
   3. cmake .. -DCMAKE_TOOLCHAIN_FILE=../vcpkg/scripts/buildsystems/vcpkg.cmake
      • CMake Error ... "msgpackc-static" is imported but not globally visible とか出たら
        • vcpkg/installed/ { x64-linux などのプラットフォーム名 } /share/msgpack/msgpack-targets.cmake の
        • add_library(msgpackc-static ... に GLOBAL を追記する修正が一時的に必要かもしれません
        • https://github.com/microsoft/vcpkg/issues/7205
   4. cmake --build .

(†1): ↓ ./vcpkg install eigen3 の終わりに表示される CMake ではこうしてね情報:

    find_package(Eigen3 CONFIG REQUIRED)
    target_link_libraries(main PRIVATE Eigen3::Eigen)

(†2): ↓ ./vcpkg install msgpack の終わりに表示される CMake ではこうしてね情報:

    find_package(msgpack CONFIG REQUIRED)
    target_link_libraries(main PRIVATE msgpackc msgpackc-cxx msgpackc-static)

パッケージの実体

• vcpkg 導入先の buildtrees, installed, packages にそれぞれソースやビルドされたライブラリーが放り込まれます
  • 良くも悪くも強引ですが、場所を変更する手段はいまのところは実質的に存在しないので、必要な場合は vcpkg の導入自体を単位として扱います https://docs.microsoft.com/en-us/cpp/build/vcpkg?view=vs-2019#per-project

Hunter

導入方法

1. Hunter をプロジェクト単位で使うための HUNTER_ROOT 用のディレクトリーを作成:
   • mkdir hunter_root (†2)
2. HunterGate をプロジェクトへ仕込む https://cpp-pm-hunter.readthedocs.io/en/latest/quick-start.html
   1. mkdir cmake
   2. HunterGate.cmake をダウンロードして配置
      • wget を使う場合: wget https://raw.githubusercontent.com/hunter-packages/gate/master/cmake/HunterGate.cmake -O cmake/HunterGate.cmake
      • PowerShell を使う場合: Invoke-WebRequest -Uri https://raw.githubusercontent.com/hunter-packages/gate/master/cmake/HunterGate.cmake -OutFile cmake/HunterGate.cmake
3. CMakeLists.txt の project よりも前に Hunter を仕込む... (†1)
   1. set( ENV{HUNTER_ROOT} "${CMAKE_CURRENT_SOURCE_DIR}/hunter_root" ) (†2)
   2. include( "cmake/HunterGate.cmake" )
   3. HunterGate( URL "https://github.com/cpp-pm/hunter/archive/v0.23.240.tar.gz" SHA1 "ca19f3769e6c80cfdd19d8b12ba5102c27b074e0" )
      • 基本的に最新リリースを確認して設定するといいはず: https://github.com/cpp-pm/hunter/releases

(†1): この仕様のため、 Hunter は add_subdirectory されるサブプロジェクト単位で使用したい場合に少し厄介です。サブディレクトリー単位で独立した CMake を呼ぶトリックを仕込むか、諦めてルートになるプロジェクトの project よりも前に Hunter を仕込むか、状況によっては悩ましい対応が必要になるかもしれません。

(†2): ~/.hunter_root や %HOMEPATH%/.hunter_root を用意して、 .bashrc や Windows の環境変数設定で HUNTER_ROOT をその場所へ設定しておくと conan のように合理的なパッケージ実体の管理方法になります。このメモの方法はプロジェクト単位の中へ Hunter のパッケージ管理と本体も押し込めたい場合の簡単なトリックの例です。

プロジェクトへのパッケージ追加方法

1. パッケージを探す... https://cpp-pm-hunter.readthedocs.io/en/latest/packages.html
   1. Eigen https://cpp-pm-hunter.readthedocs.io/en/latest/packages/pkg/Eigen.html
   2. msgpack https://cpp-pm-hunter.readthedocs.io/en/latest/packages/pkg/msgpack.html
2. CMakeLists.txt にライブラリーを追加
   1. hunter_add_package( Eigen )
   2. hunter_add_package( msgpack )
   3. find_package( Eigen3 CONFIG REQUIRED )
   4. find_package( msgpack CONFIG REQUIRED )
3. ビルド
   1. mkdir build.cmake && pushd build.cmake
   2. cmake ..
      • Hunter のパッケージビルドがここで行われるので容赦なくかなりながい時間がここでかかります
        • 妙に長いので🍵ブレイク後に見たら Eigen, msgpack のほか OpenSSL, ZLIB もフルビルドされていました...
   3. cmake --build .

パッケージの実体

• CMake から HunterGate が実行された際の HUNTER_ROOT 環境変数のディレクトリー内へ、ダウンロード、ビルドされる
  • メタ情報の管理も細かくされていて、パッケージバージョンが混乱したりする心配は無さそう
• conan のようにパッケージの実体はプロジェクトを超えて合理的に共有したい場合は適当な共有用のディレクトリーを設け、 HUNTER_ROOT 環境変数をプロジェクトの外で設定すればOK

現時点での感想

1. Windows と Ubuntu 程度の軽いクロスプラットフォーム対応性
   • 現時点では conan, vcpkg, Hunter どれでも問題になる事の方が少なさそう
     • vcpkg の msgpack では手修正が必要な問題が発生しましたが、エラーメッセージを読めば対応できる程度なのでまあ…どうだろう…プロジェクトの開発者が初心者だらけだったら…厳しいかもしれませんね…
2. ライブラリーの対応の幅広さ、抜け目の無さ
   1. 現時点での一般論としては vcpkg が他に比べて少し有能そう; OSGeo/PROJ, OpenMVG, curppp など
   2. conan, Hunter も一般性の高いパッケージに困る事はおおよそない; zlib, libjpeg, boost など
3. パッケージ検索のし易さ
   1. vcpkg が理想的かもしれません。
      • vcpkg search の動作がわりと軽快
      • 導入先の ports ディレクトリーを眺めるだけでも探せる
   2. conan search は pip のようなもっさり感はあるものの(中身はpythonだしね...)、実用十分には探せる＆耐えられる
   3. Hunter はコマンド式のインターフェースは無く、"読み物"から探すのは地味にだるいです...
4. プロジェクト単位での使いやすさ
   1. conan がとても合理的; 実体はバージョンごと共有管理するけれど使用はプロジェクト単位で特定バージョンを引っ張れる
      • しばしば conan は CMake の使い方が邪悪と言われるけれど、そもそも CMake のパッケージ管理のゆるふわ感を考えるとどうでもいいかな、むしろこういうまとめ方もユーザーには便利でいいかもーくらいにゆるっと思う程度です
   2. vcpkg はプロジェクト単位での使用方法が極めて強引ですが、プロジェクトで採用する補助ツールを git subtree / git submodule などで取り込みやすい場合には寧ろ好都合かもしれません
      • 強引なものの、結果的には、パッケージの実体と vcpkg そのものを完全にプロジェクト単位の中だけで固有に管理しやすいので、ポータビリティーを考えると悪くないかもしれません
   3. Hunter は CMake 的に複雑なソリューションの中のサブプロジェクトとしては工夫しないと採用できない点が地味にめんどくさいかも; add_subdirectory の先に配置したい場合に少し厄介
      • しばしば conan との比較で CMake が綺麗と言われているように、実際、キレイです。キレイです…が、 conan を使った後だと CMake の記述量が少しですが多い点をだるく感じてしまうかもしれません
      • このメモに残したちょっとしたトリック程度で比較的簡単にパッケージの実体と Hunter の本体をまるごとプロジェクト単位の中に埋められるので、ポータビリティー的には vcpkg と同等の強さがあります
5. 時間
   1. conan はビルド済みのバイナリーも提供してくれるので一般的な用途では便利
   2. vcpkg, Hunter は基本的にソースからビルドなので重いライブラリーを引っ張るとビルドに時間がかかります

KDE アプリが Windows/WSL/Ubuntu-19.04 環境で libQt5Core.so.5 が云々とかエラーを吐いて動かないときの対処方法のメモ

KDE なアプリたち、例えば umbrello とか kwrite とか、とにかくみんな↓のようなエラーを吐いて Windows/WSL/Ubuntu-19.04 環境で動いてくれない現象に遭遇しました。

kwrite: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory

発生した環境の状態:

• Windows 10 Pro 64-Bit (10.0.18362.535)
• WSL の Ubuntu を 19.04 へ do-release-upgrade したばかり
• X は X410 を使っています (今回の問題に直接は関係ありません)

ぐぐったら既に superuser で解決されていました:

• linux - Arch on WSL: libQt5Core.so.5 not found, despite being installed - Super User

Ripdog の Answer はおおよそ正解ですが、さらに bart がコメントしているように、少しだけ状況が異なる可能性があります。私の場合も同様。

正解の安定手順は:

1. find で libQt5Core.so.5 のパスを確認
2. strip で .note.ABI-tag を消しちゃう

のようです。

find /usr/lib -iname "*qt5core.so*"

↓

/usr/lib/x86_64-linux-gnu/libQt5Core.so
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.2

↓

sudo strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

これで、 KDE なアプリたち(というより /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 に依存するアプリたち)が少なくともこの問題については解決され動作してくれるようになります。

Windows 10: CPU 100% 張り付き問題の解決

少し前に、次の状況に気が付きました:

• Windows 10 Pro 64-Bit ( 10.0, Build 18362 ) で、
• Task Manager の CPU 負荷が Processes タブと Performance タブで全てのコアが常に 100% に張り付いた状態になる
• 但し、下図のように GL-Z などタスクマネージャーではない方法で観測するとタスクマネージャーが "うそ" の報告をしている疑いがあります
• 蛇足: マルウェアのせいじゃないと思うよ

困るような、困らないような状況ですが、少なくとも精神衛生上の問題と気持ち悪さはあります。緊急性は無さそうなのでしばらく放置していましたが、タスクマネージャーを使うと目に入るので、気になって少し調べてみると:

• CPU usage is stuck at 100% - Microsoft Community

Windows Insider 系の投稿に 2018 に WaritC が同様の問題を報告している事に気が付きました。キーワードを工夫しないと、当てずっぽうでいい加減な「どうせマルウェアだろ」的な記事ばかりググられてしまったりもしますし、この記事でも Ken Blake がさっそく「よくわからないが、たぶんマルウェアのせいだろう」と返信を付けています。

もちろん、私に先ほどまで起きていた "この問題" あるいは WaritC に起きていた "この問題" はマルウェアのせいではありませんでした。 WaritC はマルウェアの指摘にも真摯に対応しながら、最初の投稿から3日後に、

I was able to randomly find a fix on my own after reading around on the internet.

It seems like the issue came from "Power Options" (right clicking on battery icon) and when I "restore default settings for this plan" the CPU usage level dropped down to normal levels.

著者訳:

インターネットで調べたり、あちこち適当にいじってみたところ、私はこの問題を解決できました。

この問題は "Power Options" (バッテリーのアイコンを右クリックして) から、"restore default settings for this plan" すると CPU の使用状況を正常な状態まで下げられます。

と、いうわけで、私も試してみました。 "狙って探す" のは少し分かりにくい部分をポチる必要があります:

(†1): ↑この画面の "Change plan settings" のリンクをポチり、

(†2): ↑この画面の "Restore default settings for this plan" のリンクをポチると、その瞬間以降タスクマネージャーのCPU負荷の表示が期待動作する状態に回復します。

手順を整理すると:

1. スタートメニューの "Settings" (たぶん日本語だと「設定」) から
2. "Edit Power Plan" (日本語では「電源プラン」のなんとか…だと思います)
3. 画面(†1)から、選択中ならどのプランでもいいので、プランの右側にある "Change plan settings" (プラン設定を変更とか日本語では出ているのかも) のリンクをポチり、
4. 画面(†2)から、"Restore default settings for this plan" のリンクをポチる (日本語ではデフォルトの設定を復元する、とか標準の設定に戻すとかそういう表現かもしれません)

です。

すっきりしました🧙‍♀️

🎄 Happy holidays ⛄