clang_libraries_companion
v0.2.0
このリポジトリには、次のスライドデッキに関連付けられているすべてのコード例が含まれています。
スライドデッキは、以下でダウンロードできます
リポジトリは次のように編成されています。
各コードの例またはコード例のグループは、個別のcmakeプロジェクトとして構成されています。これにより、ユーザーはすべてのコード例を作成することなく、個々のコードの例を実験することができます。便利なため、2つのcmakelists.txtファイルが提供され、すべての下位プロジェクトを構築します。すべてのプロジェクトは、提供されたビルドスクリプト（これら2つのCmakeスーパービルドを呼び出す）を使用して構築できます。
このリポジトリは、GitHubアクションに基づいてCIワークフローを採用しています。新しいコミットがプッシュされるたびに、リポジトリのコード例が構築され、基本的な正気テストとして実行されます。このCIワークフローは、LLVMプロジェクト（https://apt.llvm.org/で）が提供するLLVM/Clang Ubuntu AptパッケージをGithub-Hosted Linuxランナーで使用する方法を示す例として機能します。 CIワークフローは現在、以下のいくつかの組み合わせのために構築されています。
コードの例には、次のソフトウェア依存関係があります。
これらの依存関係は、コードの例を作成する前にインストールする必要があります。
C ++標準ライブラリがSTD ::フォーマットをサポートしていない場合、FMTライブラリのカスタムバージョンを自動的にインストールして（ビルドプロセスの一部として）このサポートを提供できます。 （FMTライブラリのこのカスタムバージョンは、「フォーマット」と呼ばれる標準的なライブラリヘッダーを提供し、そのヘッダーのSTDネームスペースにいくつかの重要な宣言を配置します。）GCCのバージョン13以降に含まれるC ++標準ライブラリには、STD :: Formatのサポートがあります。
便利なため、必要なすべてのソフトウェア依存関係を含むコンテナ化された環境を構築するために、DockerFileが提供されます。このDockerFileの詳細については、後のセクションに記載されています。
コードの例では、Cmakeベースのビルドプロセスを採用しています。関連する例の各コードの例またはグループは、個別のcmakeプロジェクトとして構成されています。便利なため、すべてのコードの例を1つのステップで構築するためのスクリプトが提供されます。
コードの例の一部には、STD ::形式（C ++ 20で導入）が必要です。使用されているC ++標準ライブラリの実装がSTD ::フォーマットをサポートしていない場合、FMTライブラリのカスタムバージョンを自動的にインストールして（ビルドプロセスの一部として）このサポートを提供できます。
すべてのコードの例を作成する（およびオプションで関連するすべてのデモを実行）、次を実行します。
環境を初期化して、必要なソフトウェア依存関係（例、実行可能ファイル、ヘッダー、またはライブラリ）がビルド時に正常に見つかります。通常、このステップは、ソフトウェアの依存関係の一部が通常、ビルドプロセスでは見つからない場所にインストールされている場合にのみ必要です。このステップが必要な場合、それは次のように見えるかもしれません：
# Initialize the following variables used to configure the
# environment:
# cmake_dir
# - The directory under which CMake has been installed
# (e.g., /usr, /usr/local).
# clang_dir
# - The directory under which LLVM/Clang has been installed
# (e.g., /usr, /usr/local).
# gcc_dir
# - The directory under which GCC has been installed
# (e.g., /usr, /usr/local).
# boost_dir
# - The directory under which Boost has been installed
# (e.g., /usr, /usr/local).
# Use the preceding variables to configure the environment by
# setting several key environment variables:
export BOOST_INCLUDEDIR=$boost_dir/include
export BOOST_LIBRARYDIR=$boost_dir/lib
export PATH=$cmake_dir/bin:$clang_dir/bin:$gcc_dir/bin:$PATH
export LD_LIBRARY_PATH=$BOOST_LIBRARYDIR:$LD_LIBRARY_PATH
export CPATH=$boost_dir/include:$CPATH
現在の作業ディレクトリを、クローン化されたGITリポジトリの作業ツリーのトップレベルディレクトリに設定します。
適切なオプションを使用してビルドスクリプトを呼び出します。名目上、スクリプトは次のように呼び出されます。
./build --defaults
使用されているC ++標準ライブラリがSTD ::フォーマットをサポートするために発生する場合、「-no-fmt」オプションを上記のビルドスクリプトの呼び出しに追加できます（FMTライブラリのカスタムバージョンが使用されないように）。つまり、次のコマンドを使用できます。
./build --defaults --no-fmt
ビルドスクリプトは、多数のオプションをサポートしています。詳細な使用情報については、「-H」または「 - ヘルプ」オプションを使用してスクリプトを呼び出します。コマンドライン引数は、左から右に処理されます。したがって、設定が複数のコマンドラインオプションによって確立される場合、右端のオプションからの設定が有効になります。
必要に応じて、コマンドでデモスクリプト（基本的な正気テストとして）を実行します。
./build --demo
ビルドプロセスの出力はディレクトリに配置されます。
各Cmakeプロジェクトの出力は、そのプロジェクトと同じ名前を持つディレクトリに配置されます。たとえば、スライドデッキの例からcyclomatic_complexityと呼ばれるプロジェクトのビルド出力は、ディレクトリに配置されています。
slides/examples/tmp_build/cyclomatic_complexity
ほとんどのプロジェクトには、デモスクリプトがあります（「デモ」と呼ばれるか、「デモ」を含む名前が付いています）。たとえば、cyclomatic_complexityプロジェクトのデモスクリプトを実行するには、コマンドを使用します。
slides/examples/tmp_build/cyclomatic_complexity/demo
このリポジトリのコード例を構築および実行するために必要なソフトウェア依存関係のすべてを備えたポッドマン/ドッカーコンテナを作成するために使用できるDockerFileが提供されています。このコンテナ化された環境の使用方法については、以下に説明します。これらの命令は（rootless）ポッドマンを使用していますが、ポッドマンとドッカープログラムにはほぼ同じコマンドラインインターフェイスがあります。したがって、指示の「ポッドマン」に「Docker」を置き換えることができるはずです。
$ top_dirは、クローン化されたgitリポジトリの作業ツリーのトップレベルのディレクトリ（つまり、現在読んでいるreadme.mdという名前のファイルを含むディレクトリ）を示します。 $ top_dirは絶対的なパスである必要があることに注意してください。
コマンドを使用して、作業ツリーのトップレベルディレクトリに作業ディレクトリを設定します。
cd $TOP_DIR
コマンドを使用してコンテナを構築します。
podman build --tag cl-demo - < podman/Dockerfile
コンテナの一時的なインスタンスを作成し、コマンドを使用してコンテナ内のバッシュシェルを実行します。
podman run -i -t --rm -v $TOP_DIR:$TOP_DIR:rw -w $TOP_DIR
--cap-add=SYS_PTRACE --security-opt label=disable
cl-demo /bin/bash
「-cap-add」および「 - -security-opt」オプションは必要ない場合があることに注意してください。
バッシュシェルが終了した後にコンテナを削除したくない場合は、「-RM」オプションを省略します。
以前のセクションで詳細に説明されているように、デモスクリプトの構築と実行に進みます。たとえば、コンテナで実行されているBashシェルから次のコマンドを呼び出すことがあります。
./build --defaults
アドレス消毒剤（ASAN）の使用は、たとえば、コードが実行されているプラットフォームの癖に問題がある場合があります。 ASANのランタイム動作は、環境変数ASAN_OPTIONSを介して制御できます。その値は、キー価値ペアのコロン分離リストです（例：「冗長= 1：Detect_Leaks = 0」）。
一部のプラットフォームでは、コードの例で使用されるライブラリの一部は、メモリリークがあることが観察されています。 Asanがメモリリークを持っている一部のライブラリについて不満を述べている場合、ASAN_OPTIONS環境変数のASANオプションのリストに「Detect_Leaks = 0」を追加することにより、メモリリーク検出を無効にすることができます。たとえば、ASAN_OPTIONSは次のように設定できます。
ASAN_OPTIONS=detect_leaks=0
メモリのユーザー中毒は、LLVM/Clangがどのように構築されたかに応じて、ASAN（すなわち、ポジションの使用後エラー）からの誤検知をもたらすことがあります。これは、LLVM/Clangライブラリとこれらのライブラリを使用してアプリケーションでユーザー中毒がどのように処理されるかについての矛盾が原因である可能性があります。この問題が発生した場合、ASAN_OPTIONS環境変数のASANオプションのリストに「Allow_user_poisoning = 0」を追加することにより、ユーザー中毒を無効にすることができます。たとえば、ASAN_OPTIONSは次のように設定できます。
ASAN_OPTIONS=allow_user_poisoning=0
このソフトウェアは、ほとんどのUNIXベースのシステムで動作する必要があります（必要なソフトウェア依存関係がインストールされている場合）。 Github CIワークフロー（上記）により、ソフトウェアがUbuntu LinuxとMacOSを合理的に確実に構築および実行することを保証します。著者の主な開発プラットフォームはFedora Linuxです。そのため、ソフトウェアもこのプラットフォームでもかなり確実に動作するはずです。
