ZigはCMakeの代替となるか
既存のプロジェクトで使用しているコンパイラを置き換えるだけで、Zigに付属しているCコンパイラを利用できる。 クロスビルドが標準で可能 上でも述べた通り、Zigは標準でクロスコンパイルが可能である。 Zig libcのTaget一覧 ❯ zig targets | jq ".libc" [ "aarch64_be-linux-gnu", "aarch64_be-linux-musl", "aarch64_be-windows-gnu", "aarch64-linux-gnu", "aarch64-linux-musl", "aarch64-windows-gnu", "aarch64-macos-none", "aarch64-macos-none", "armeb-linux-gnueabi", "armeb-linux-gnueabihf", "armeb-linux-musleabi
CMake 3.26 日本語
CMake 3.26 日本語 CMake Properties: Source Files ABSTRACT AUTOUIC_OPTIONS EXTERNAL_OBJECT GENERATED HEADER_FILE_ONLY INCLUDE_DIRECTORIES KEEP_EXTENSION LANGUAGE MACOSX_PACKAGE_LOCATION OBJECT_DEPENDS OBJECT_OUTPUTS SKIP_AUTOGEN SKIP_AUTOMOC SKIP_AUTORCC SKIP_AUTOUIC SKIP_PRECOMPILE_HEADERS SKIP_UNITY_BUILD_INCLUSION Swift_DIAGNOSTICS_FILE SYMBOLIC UNITY_GROUP VS_COPY_TO_OUT_DIR VS_CSHARP_tagname VS_D
C++ のパッケージマネージャーの選択メモ( conan vs. vcpkg vs. Hunter on Windows and Ubuntu ): C++ 実装がサブプロジェクトとして内包されるクロスプラットフォームアプリのリポジトリーの場合 - C++ ときどき ごはん、わりとてぃーぶれいく☆
タイトルが少しややこしいので最初に整理します。 このメモは: C++ のパッケージマネージャーの選択のはなし ただし: アプリはクロスプラットフォーム ( このメモでの具体例は Windows-10 & Ubuntu-19.04 ) アプリ全体(=このメモでは「ソリューション」とします)はいくつかの構成部品(=このメモでは「プロジェクト」とします)に分けて作られる プロジェクトの1つ以上に C++ を採用したい そのプロジェクト単位で C++ のライブラリーを管理できるパッケージマネージャーを導入したい → どうするのが楽そうかな のメモです。 選択肢と大雑把な検討 conan https://conan.io/ クロスプラットフォーム対応の C++ のパッケージマネージャーが欲しいの悩みに答えてくれる定番。 CMake でごにょごにょする vcpkg https://github.com
CMake: プリコンパイル済みヘッダーの作成と利用 - Qiita
はじめに みなさん、こんにちは。今回は、CMake でのプリコンパイル済みヘッダーの作成と利用方法について書いていきます。 プリコンパイル済みヘッダーとは？ C++ において、Boost の使用やテンプレートメタプログラミングは必須といっても過言ではありません。しかしこれらを駆使すると、ビルド時間がすぐに Boooooooooooooooost してしまいます。ビルド時間の増大は開発速度の低下を招き、プログラマの精神的負担にもなります。そのため、どうにかして高速化しなければなりません。高速化の手法にはいくつかありますが、機械的にできるものとしてプリコンパイル済みヘッダーの使用が挙げられます。プリコンパイル済みヘッダーとは、よく使うヘッダーをあらかじめコンパイルしておくことにより、そのヘッダーを使うコードのコンパイル速度を向上させることができるものです。しかし、プリコンパイル済みヘッダーは各
中規模なC++の新しいプロジェクトを作るときにやるべきこと 2016年版 - Qiita
C++で新しいプロジェクトを作成するときに自分が定型的にやっていることを備忘録的にまとめました。完全に我流なので「こういうやり方もあるよ」などのアドバイスは歓迎です。 この記事中では各ファイルで説明が必要な部分だけを示しますが、全てのサンプルはgithubにおいてあります。 cpp-template: https://github.com/m-mizutani/cpp-template 前提 UNIXベースのCLIで動作するアプリケーション or ライブラリを作る コンパイルはcmakeを使用する ファイル名はソースコードが*.cc、ヘッダファイルが*.hppだとする サンプルではcpptemplate というプロジェクト名だと仮定します プロジェクト用ファイルの準備 CMakeList.txt サンプル cmakeでビルドするための設定ファイルです。このサンプルではCLIアプリケーション
CMake 簡易まとめ - Qiita
autotools に比べてとても使いやすい。 CMakeLists.txt ビルド対象のディレクトリーに CMakeLists.txt を配置することで cmake コマンドが対象だと認識してくれるようになる。 最低限必要な設定は次になる。 cmake_minimum_required CMakeLists.txt に記載されている内容を実行するにあたって必要な CMake のバージョンを明示する add_executable 実行ファイル名と、そのビルドに必要な c / cpp ファイルの指定 ヘッダーファイルはここに指定しなくても、更新すると勝手に認識してリビルド対象にしてくれる target_link_libraries リンクするライブラリーの指定 gcc に -lfoo と指定していた場合、 foo とだけ書く ビルド対象の分割 複数のビルド対象がある場合、ひとつの CMake
GoogleTest + CMakeでC++の実践的なユニットテスト環境を構築する：その２（カバレッジ表示） - Qiita
背景と目的 前回の続きの記事です。 下記に対応します。 背景と目的 ⑦カバレッジを行単位で表示できること（別途記載予定） 前回はユニットテストの実行環境を構築するだけで終わりましたが、それに加えて htmlのカバレッジレポートを出力できるようにします。 サンプルコード 本記事は、ミニマムなサンプルコードを追っていけば目的を達成できるようになっています といってもコードのほうに詳しいコメントを記述しているわけではないので、簡単に解説を下記に記述します。 サンプルコードはこちら お試し環境 os: Ubuntu 16.04 LTS tool: gcc-5.4.0, cmake-3.10.2, lcov-1.12 lcovがインストールされていることが前提です lcovのインストール方法例（他の方法もあると思います）： $ mkdir ~/tmp $ wget https://github.co
GoogleTest + CMakeでC++の実践的なユニットテスト環境を構築する：その１ - Qiita
背景と目的 googletestを導入するための情報は、既に多くの先輩方により記述されていますが、本記事では、それらに＋αの情報を加え、実際の開発現場にすぐに適用できる実践レベルの内容としてまとめることを目的とします。 それでは、ここで想定している実践的なテスト環境とは何かと言うと ①テストフレームワークのインストール方法がスクリプト化されていること ②テストフレームワークのバージョンが固定されていること ③テストケースを追加する度にプロジェクトファイル（Makefileとか）を編集させないこと ④テストファイルとテスト対象ファイルが対になっていること（ClassA.cpp、ClassATest.cpp、など） ⑤mockを実装する手段が提供されていること ⑥IDEと統合してテストのデバッグができること（別途記載予定） ⑦カバレッジを行単位で表示できること（別記事） ⑧CIでテスト結果を表
CMakeでビルドした実行プログラムのあるディレクトリにリソースファイルをコピーする - yuki-koyama's blog
やりたいこと CMakeを用いてプロジェクトを管理しているときに、ビルドした実行ファイルと同じディレクトリ（またはそこから相対的に定義されるディレクトリ）に画像データ等のリソースデータをコピーしたいという状況を考える。 リソースファイルは、例えば次のように定義されているとする。 file(GLOB RESOURCE_FILES ${CMAKE_CURRENT_SOURCE_DIR}/resources/*.png) file GLOB https://cmake.org/cmake/help/latest/command/file.html#glob 問題点 ビルド環境ごとにビルドした実行プログラムが配置されるディレクトリは異なる可能性がある。 例えば、Makefileを生成してmakeとした場合には${CMAKE_CURRENT_BINARY_DIR}に実行プログラムが配置されるが、Xc
C++ のユニットテストをいい感じにする - Qiita
C++ のユニットテストを簡単にあつかえるようにしてみた。 要素としては次。 Google Test https://code.google.com/p/googletest/ 現在一番扱いやすい C++ ユニットテスト用フレームワークだと思う。 CMake との親和性が高いのもよい。 CMake http://www.cmake.org/ ユニットテストのコンパイルを楽にするために。 実行と結果の要約表示は付属の CTest を使うといい感じになる。 ここでは CMake まわりの設定について説明していく。 Google Test の使い方については各自で調べてください。 サンプル CMake の都合上ディレクトリー構造がキモになってくるのでわかりやすさのためにサンプル作ってみた。 トップで次のコマンドを打つとテストまで完了する。 project root/ cmake/ # CMake
CMake ExternalProject 事始め - Qiita
CMake の ExternalProject モジュールの使い方についての日本語記事が少ないように感じたので、忘備録も兼ねて。 ExternalProjectとはなんぞや? ソースツリーの外部から別のプロジェクトを持ってきてビルド、インストールまでやってしまえるという機能です。 どういう時に便利か? *unix 系 OS だと大抵のライブラリは apt や yum, pacman などで簡単にインストール出来ますが Windows じゃなかなか大変です。ExternalProject が提供する ExternalProject_Addを使うことで外部依存ライブラリのセットアップを自動化出来ます。 サンプル OpenGL 系のライブラリ glfw に依存するプログラムを例にします。まず CMakeLists.txtから 幾つかポイントを列挙していきます。 cmake_minimum_req
お手軽な xxx-config.cmake の作成方法 - Qiita
モチベーション CMake でライブラリを作成する際に、<foo>-config.cmake ファイルを作成しておくと、そのライブラリを利用するCMakeプロジェクトで find_package コマンドを利用して検索できます。 この foo-config.cmake を手で作成することもできますが、これはなかなか骨の折れる作業になります。 そこで、この記事では install(EXPORT) コマンドを使用して、foo-config.cmake を自動生成するCMakeLists.txtの書き方について解説します。 この方法のメリット FindFoo.cmake を書く必要がない。 クライアント側のCMakeLists.txt で find_package(foo) した後に、 target_link_libraries(foo) するだけで、自作のライブラリをリンクできる。 おおまかな
CMakeで大きめのプロジェクトを構成するためのメモ - Qiita
ここ2週間ぐらい、CMakeジェネレータのqtpmの改良を続けてきました。生成されたファイル自身は、いろいろな試行錯誤の結果が凝縮されたものです。こういう意図をもってこのように変更してきたよ、というのをまとめます。 ちなみに、生成するCMakeLists.txtはライブラリ用とアプリ用と2パターンあり、ライブラリ用の完成品は上記のリンクに貼っています。アプリ用の完成品はこのページの下部にあります。あと、書きながらちょちちょいミスを見つけて手修正したところもあるので、まだ検証が漏れている所も少しあります。特にWindows周り。検証して間違いがあったら適宜修正していきます。 大規模とは何か？ まずは大きいプロジェクトとは何か、というところから。簡単に説明すると、独立した部品に分けられるようなアプリを想定しています。独立した部品は個別のパッケージに入ります。その中には、サンプルコードとテストコ
CMake: 便利なコマンド・変数 - Qiita
はじめに みなさん、こんにちは。今回は CMake スクリプトを記述する上で便利なコマンドや変数について紹介していきます。 list()コマンド リストの長さ取得や追加など、リスト操作の便利な機能を提供するコマンドです。CMake: リストで詳しく述べられています。 file()コマンド file()コマンドは、各種ファイル操作やファイルの検索に加えて、ダウンロードやアップロード機能など様々な機能を提供します。よく使いそうな機能を下記に示します。 ファイル生成・削除と入出力 WRITE・APPEND file(WRITE <filename> [<content1> ...]) file(APPEND <filename> [<content1> ...]) WRITEはファイル<filename>に指定した文字列<content1> ...を出力します。このとき、指定したファイルが存在し
CMake: 条件分岐 - Qiita
はじめに みなさん、こんにちは。今回は条件分岐について書いていきます。 構文 条件分岐にはif()コマンドを使います。このif()コマンドは、elseif()・else()・endif()コマンドとセットで使用します。構文は下記のとおりです。 if(expression) # then section. COMMAND1(ARGS ...) COMMAND2(ARGS ...) ... elseif(expression2) # elseif section. COMMAND1(ARGS ...) COMMAND2(ARGS ...) ... else(expression) # else section. COMMAND1(ARGS ...) COMMAND2(ARGS ...) ... endif(expression) if — CMake 3.0.2 Documentation e
CMake: キャッシュ変数と環境変数 - Qiita
はじめに みなさん、こんにちは。CMakeの変数には、いままで使用してきたものの他に、キャッシュ変数と環境変数というものが存在します。今回は、これらについて書いていきます。 キャッシュ変数とは、文字通りキャッシュされた変数のことで、値がキャッシュファイルに保存されています。そのため、キャッシュファイルが削除されるまで存在し続けます。主な用途として、使用するコンパイラや、依存ライブラリのパスなどの格納です。これらは、CMakeの実行毎に設定する必要はないので、キャッシュ変数を用いて永続化します。また、キャッシュ変数は、通常の変数と違って、スクリプトのどこからでも参照・設定ができます。 このキャッシュ変数の操作方法は以下のようになっています。 生成・代入 キャッシュ変数の生成や代入には、set()コマンドのCACHEオプションを用います。 変数名<variable>および値<value> ..
cmake : externalproject で zlib と libpng を扱う例 - Qiita
目的 CMake の ExternalProject によって既存のプロジェクトへ zlib と libpng を取り込み扱えるようにする方法を紹介したい。 externalproject 例 external_zlib.cmake cmake_minimum_required( VERSION 3.2 ) include_directories(${CMAKE_CURRENT_BINARY_DIR}/include) link_directories(${CMAKE_CURRENT_BINARY_DIR}/lib) include( ExternalProject ) set( zlib_source_path ${CMAKE_CURRENT_BINARY_DIR}/external/zlib/src/external_zlib/ ) set( zlib_cmake_file_path
C++応用講座CMake編 | Theolizer®
実践C++応用講座CMake編 【無料】 ビルド・システム（いわゆる Makefile） C++で実用的なプログラムを開発する時には、効率的にビルドできるようビルド・システム（いわゆる Makefile のことです）を用意することが一般的です。 １つのプロジェクトには多くのソース・ファイルが含まれることが多く、個人で開発する場合でも十数個～数十個程度になることも少なくありません。そのようなプロジェクトでプログラムを修正して走らせる度に全てのソースをコンパイル／リンクしていると時間がかかりすぎて効率が悪いです。 そこで、必要なソースだけをコンパイル／リンクするための仕組みがビルド・システムです。これを使うとデバッグの効率がたいへん上がります。（ですので、事実上必須と言っても過言ではないと思います。） ビルド・ツール問題 しかし、問題があります。ビルド・システムはプロジェクト毎に多くの設定
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CMakeのカレンダー | Advent Calendar 2014 - Qiita
GitHub - dev-cafe/cmake-cookbook: CMake Cookbook recipes.