X



ビルド自動化ツールCMake Part.1
0001蟻人間 ◆T6xkBnTXz7B0 2021/06/12(土) 20:08:31.78ID:bymgAWyc
CMakeは、コンパイラに依存しないビルド自動化のためのフリーソフトウェアです。主にC/C++のビルド管理で使用され、様々なビルド環境に対応しています。Windows、Linux、MacどこでもOK。

https://cmake.org/

基本的な使い方はまず、ビルド環境にCMakeをインストールした後で、ビルド方法を記述したテキストファイルCMakeList.txtをソースと同じ場所に作成した上で、
cmakeをジェネレータを指定して実行するとMakefileやプロジェクトファイルなどが生成されるので、それを使ってビルドします。
ジェネレータの一覧は-Gオプションを付けてcmakeを実行すると見られます。
0022蟻人間 ◆T6xkBnTXz7B0 2021/06/13(日) 13:59:51.46ID:grfIiy8/
>>21
cmakeに成功すると、CMakeCache.txtというファイルができる。
この中に変数の設定内容が一時的に保存されている。
0023蟻人間 ◆T6xkBnTXz7B0 2021/06/13(日) 15:30:14.97ID:otNLJkw4
間違えずに書く自信のある人なら、CMakeCache.txtに書かれてる内容を直接書き換えてもいい。
0024デフォルトの名無しさん2021/06/14(月) 10:48:01.94ID:LnG83xz5
>>17
蟻は調べながら受け売りコピペしてるだけ
結局自分で調べた方が早い
0025デフォルトの名無しさん2021/06/14(月) 13:15:02.79ID:shEIUH7U
調べて載せてくれてるならいいじゃないのコピペだって
多少の間違いは周りが訂正してあげれば十分
そんな叩いてばかりしてたらコミュニティが過疎っしまいますよ
0027デフォルトの名無しさん2021/06/14(月) 18:27:19.15ID:6p9bp5Dj
糞コミュニティなんていくらでもあるんだから、自分に必要ないと思ったら
寄っていかなきゃいいだけ。
0028デフォルトの名無しさん2021/06/14(月) 18:53:14.11ID:U7CM/gao
Part 1とか付けると2まで伸びないというジンクスがある。
0029デフォルトの名無しさん2021/06/15(火) 01:22:59.73ID:cmWMd34J
いつも思うことだがツールチェインとか特に
便利にしようと思って作ったのは気持ち的にはわからんでもないけど
かえって手間が増えてんだよねえ・・

移植作業が必要だのなんだのいっても普通にMakefileでいいわってなる
たいした手間じゃないしな
他の奴らも全てに精通してるわけじゃないし
0030デフォルトの名無しさん2021/06/15(火) 15:30:47.00ID:dTl1pSLY
cmakeスレも昔いくつかあったな
0031デフォルトの名無しさん2021/06/15(火) 18:46:08.38ID:jlLB8m57
>>29
いや全然違う。
0033デフォルトの名無しさん2021/06/15(火) 20:23:44.43ID:ULdPzagS
makeに余計なこと書きすぎなのがいけない。酷いのになるとコロンの右側にstdio.hがあったりする。gcc -Mの出力をそのまんま喰わせてる感じ
0034デフォルトの名無しさん2021/06/15(火) 23:41:38.62ID:0F6z4l8H
cmakeは宣言型、makefileは手続型みたいな感じかな
makefileはコマンドやシェルスクリプトを使って何でもできちゃうから他人には読めないようなものになってることがある
0035デフォルトの名無しさん2021/06/16(水) 18:27:05.85ID:z1aHwQBP
makeの場合、環境変数PATHの切り替えで32bit用と64bit用のコンパイラが簡単に切り替えられるが、
cmakeは余計なことをしてくれるので不具合が発生する。

cmake -G "Visual Studio 16 2019" -A Win32 ..
こっちは動くが
cmake -G "Visual Studio 16 2019" -A Win64 ..
こっちは動かない。
ただ、何もしないと勝手にWin64のコンパイラを起動するので指定なしで代用できる。
この時のCMakeLists.txtは自分の書いたものでなくて、そこそこ有名なGitHubのソフトのものなので、
CMakeLists.txtの問題でなく、cmakeそのものの問題だと予想される。

さらに、/MT, /MD, /MTd, /MDdと四種類のライブラリをビルドしようとすると
勝手にコンパイルスイッチをいじられるのでマクロを使って工夫する必要が出てくる。

こういうのを考慮するとcmakeにすると互換性ばっちりとは言い難い。
簡潔なMakefileを書けるなら、そっちで配布した方が結果的に互換性が高いと思う。
0037◆QZaw55cn4c 2021/06/16(水) 19:13:04.42ID:ujIwgEeO
昔の教科書で習った make を使うことにしています、内部をしっかり把握しているのでこれが一番いろいろやりやすいのです
https://www.a;mazon.co.jp/dp/4871481689/
https://www.a;mazon.co.jp/dp/4871482006/
0038蟻人間 ◆T6xkBnTXz7B0 2021/06/16(水) 19:13:45.91ID:Qk2ktN9D
>>35
/MT, /MD, /MTd, /MDdについてだが、CMake 3.15よりMSVC_RUNTIME_LIBRARYという変数が使えるらしい。

https://cmake.org/cmake/help/latest/prop_tgt/MSVC_RUNTIME_LIBRARY.html
https://stackoverflow.com/a/56490614

ターゲットを分けて、それぞれについてset_propertyすれば可能。

add_executable(foo1 foo.c)
set_property(TARGET foo2 PROPERTY
MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")
add_executable(foo2 foo.c)
set_property(TARGET foo2 PROPERTY
MSVC_RUNTIME_LIBRARY "MultiThreadedDLL$<$<CONFIG:Debug>:Debug>")
...

3.15より前は、ちょっとややこしいコードになる。
0040デフォルトの名無しさん2021/06/16(水) 19:33:04.22ID:Qk2ktN9D
>>38
訂正。
「MultiThreadedDLL$<$<CONFIG:Debug>:Debug>」
じゃなくて
「MultiThreaded$<$<CONFIG:Debug>:Debug>DLL」。
0041蟻人間 ◆T6xkBnTXz7B0 2021/06/16(水) 19:38:16.75ID:Qk2ktN9D
「$<$<CONFIG:Debug>:Debug>」というのはgenerator expressionsの一種で、
デバッグ版のときは"Debug", リリース版のときは空文字列に展開されるらしい。

つまり、
「MultiThreaded$<$<CONFIG:Debug>:Debug>DLL」
は、デバッグ版では「MultiThreadedDebugDLL」となり、
リリース版では「MultiThreadedDLL」となる。

なお、MSVC_RUNTIME_LIBRARYを使う場合は、
cmake_minimum_required(VERSION 3.15)の後に
cmake_policy(SET CMP0091 NEW)も付けた方がいいらしい。
0042デフォルトの名無しさん2021/06/16(水) 20:48:17.12ID:z1aHwQBP
そうすると四種類のビルドをやるにはこうすると出来るけど、
[ --build . --config Release ]
この場合のReleaseとDebugとの関係性はどうなるの?

cmake_minimum_required(VERSION 3.15)
set(SRC a.cpp b.cpp c.cpp d.cpp e.cpp f.cpp g.cpp h.cpp i.cpp)

add_library(xx_mt ${SRC})
add_library(xx_md ${SRC})
add_library(xx_mtd ${SRC})
add_library(xx_mdd ${SRC})
set_property(TARGET xx_mt
PROPERTY MSVC_RUNTIME_LIBRARY "MultiThreaded")
set_property(TARGET xx_mtd
PROPERTY MSVC_RUNTIME_LIBRARY
"MultiThreaded$<$<CONFIG:Debug>:Debug>")
set_property(TARGET xx_md
PROPERTY MSVC_RUNTIME_LIBRARY "MultiThreadedDLL")
set_property(TARGET xx_mdd
PROPERTY MSVC_RUNTIME_LIBRARY
"MultiThreadedDLL$<$<CONFIG:Debug>:Debug>")
target_include_directories(xx_mt PUBLIC "../include")
target_include_directories(xx_md PUBLIC "../include")
target_include_directories(xx_mtd PUBLIC "../include")
target_include_directories(xx_mdd PUBLIC "../include")
0043デフォルトの名無しさん2021/06/16(水) 21:09:31.72ID:z1aHwQBP
うーん、あとこれだと自分で記述する場合はいいけど、
GitHubとかで取ってきたgcc用のtar-ballの移植の場合は 
MSVC_RUNTIME_LIBRARYのためのTARGET沢山増設して
CMakeLists.txtが殆ど書き直しに近い状態になるなあ
0044蟻人間 ◆T6xkBnTXz7B0 2021/06/16(水) 21:25:12.16ID:woJNV48Q
う〜ん、ターゲットは二種類でいいんじゃないか。generator expressionsでデバッグとリリースの差異を吸収できるし。
結局、IDEでデバッグ・リリース切り替えないといけないっしょ。
0045デフォルトの名無しさん2021/06/16(水) 21:27:08.88ID:z1aHwQBP
それって二種類書けば --configのDebug/Releaseで四種類そろうって意味?
0046蟻人間 ◆T6xkBnTXz7B0 2021/06/16(水) 21:33:26.89ID:woJNV48Q
そうだよ。プロパティに指定したgenerator expressionの
「MultiThreaded$<$<CONFIG:Debug>:Debug>DLL」は、「MultiThreadedDebugDLL」と
「MultiThreadedDLL」になる。
0048デフォルトの名無しさん2021/06/16(水) 21:57:56.14ID:z1aHwQBP
そうなるとこれでいいんだ。ありがとう。

cmake_minimum_required(VERSION 3.15)
set(SRC a.cpp b.cpp c.cpp d.cpp e.cpp f.cpp g.cpp h.cpp i.cpp)

add_library(xx_mt ${SRC})
add_library(xx_md ${SRC})
set_property(TARGET xx_mt
PROPERTY MSVC_RUNTIME_LIBRARY
"MultiThreaded$<$<CONFIG:Debug>:Debug>")
set_property(TARGET xx_md
PROPERTY MSVC_RUNTIME_LIBRARY
"MultiThreadedDLL$<$<CONFIG:Debug>:Debug>")
target_include_directories(xx_mt PUBLIC "../include")
target_include_directories(xx_md PUBLIC "../include")
0051デフォルトの名無しさん2021/06/16(水) 22:11:55.13ID:z1aHwQBP
これが正解になるのかな

cmake_minimum_required(VERSION 3.15)
set(SRC a.cpp b.cpp c.cpp d.cpp e.cpp f.cpp g.cpp h.cpp i.cpp)

add_library(xx_mt ${SRC})
add_library(xx_md ${SRC})
set_property(TARGET xx_mt
PROPERTY MSVC_RUNTIME_LIBRARY
"MultiThreaded$<$<CONFIG:Debug>:Debug>")
set_property(TARGET xx_md
PROPERTY MSVC_RUNTIME_LIBRARY
"MultiThreaded$<$<CONFIG:Debug>:Debug>DLL")
target_include_directories(xx_mt PUBLIC "../include")
target_include_directories(xx_md PUBLIC "../include")
0052デフォルトの名無しさん2021/07/11(日) 15:46:00.11ID:lbKLD5N+
結局こうやって人を実験台にする気満々で初めて誰にも相手にされなくなるんだよね。
メタ系の言語を推すバカの末路だわ。
0053蟻人間 ◆T6xkBnTXz7B0 2021/07/19(月) 23:06:43.32ID:6UpSDY/2
バーカバーカ
ヘビメタだぜ。奉ろうベイビー!

みんな優秀だから質問しなくてもできる。
偉い偉い。
0054デフォルトの名無しさん2021/09/14(火) 01:26:01.72ID:Mj50vLs9
広く使われてるけどあんまり話題がないのな
0055デフォルトの名無しさん2021/09/14(火) 06:15:43.87ID:pTMW8GY7
自作自演の即死スレ
0056デフォルトの名無しさん2021/09/15(水) 11:48:33.99ID:PYzW5a+n
そもそもマルチOSで出そうなんて苦労の割にメリット低いわ。
それもわからんバカがこういうデラックスなツールを使いたがるんだよね。
0057デフォルトの名無しさん2021/09/15(水) 19:05:46.01ID:5Un5Xbsb
VSCodeだけでC++やろうとするとこれが一番楽なんよ。マルチは苦労増えるだけやな
0058デフォルトの名無しさん2021/09/15(水) 23:44:18.94ID:9XE/xHox
cmakeってそんなにデラックスかな?
マルチプラットフォームでなくてもmakefile直書きよりメリットあると思うけど

makefile → コンパイルやリンクなど手続きを記述していく
cmake → 手続きではなく関係性などを定義していく
0059デフォルトの名無しさん2021/09/16(木) 06:19:41.69ID:QQbmBwad
広く使われることを考えてなかったような設計だよな
なんかいまいち近代的じゃない
0060デフォルトの名無しさん2021/09/22(水) 02:27:13.15ID:H7+/Tu0q
>>58
その程度の用途でmakefileも満足に書けないならc/c++での開発なんかするべきじゃない。
0061デフォルトの名無しさん2021/09/22(水) 09:37:25.13ID:85DYkwM1
そんなこといったって・・・
プラットフォームごとに使えるコマンドとか違うじゃん
cmakeに関係性を記述して各プラットフォームごとのMakefileは自動生成のほうが楽なんだもん
0062デフォルトの名無しさん2021/09/22(水) 19:08:29.74ID:xKA5BBWf
大した差ではないし、その差が理解できないやつは問題起きた時に明らかに詰むからやめろや。
0063デフォルトの名無しさん2021/09/22(水) 21:21:13.37ID:85DYkwM1
ごめんね・・
0065デフォルトの名無しさん2021/09/23(木) 00:37:14.36ID:1QHTb9H7
便利だと思えば自分で使えば良いだけで他人に強制するものではないんだよ
https://www.tokyo-np.co.jp/article/132305
0069デフォルトの名無しさん2021/10/04(月) 08:16:59.56ID:S53xZnhz
手元のCのプロジェクトをmakefileからcmakeへ移行したお陰でVSでビルド出来るようになったし、ninjaでもビルド出来るようになって、こっちはビルドが爆速になって良いことしかない
0070デフォルトの名無しさん2021/10/06(水) 17:43:31.95ID:XJEs7oM2
おめ
0071デフォルトの名無しさん2021/12/31(金) 11:32:54.51ID:+Lg1Sgs9
configureオプションとcmakeとを対照できる手段あるかな?

ClamAVのビルドツールがcmakeになってしまったので、指定していたconfigureオプションをcmakeに翻訳してやらないとならない。
レスを投稿する


ニューススポーツなんでも実況