autoconfの場合、基礎的な仕組みとad hoc なルールが明確に切り分けられてて、 後者はすべてマクロで構築されてるので、足りない部分は既存のマクロを参考に自分で用意するとか容易だけど、 CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、 CMakeであらかじめ対応しているプラットフォーム向けは簡単な記述で済むし実行速度も速いけど、 ちょっと想定から外れた使い方しようとすると途端に面倒くさくなって落差が激しい感じ。
よく知らない頃は ad hoc なルールの類は全部組み込みスクリプティング言語で書いてあるかと思ってたら 全然そうじゃないので、なんかコレジャナイ感が。
CMake (スコア:1)
CMakeホントにいいかなあ。
autoconfの場合、基礎的な仕組みとad hoc なルールが明確に切り分けられてて、
後者はすべてマクロで構築されてるので、足りない部分は既存のマクロを参考に自分で用意するとか容易だけど、
CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、
CMakeであらかじめ対応しているプラットフォーム向けは簡単な記述で済むし実行速度も速いけど、
ちょっと想定から外れた使い方しようとすると途端に面倒くさくなって落差が激しい感じ。
よく知らない頃は ad hoc なルールの類は全部組み込みスクリプティング言語で書いてあるかと思ってたら
全然そうじゃないので、なんかコレジャナイ感が。
Re:CMake (スコア:0)
ほんとこれ
さらにつけ加えると互換性問題も以外と酷い
cmake_minimum_required (VERSION 3.10.1) みたいなのがまれに良く出てくる
ArchやGentooなどの、最新版こそ正義みたいなポリシーのディストリ使ってるならともかく
stableって古いことだと勘違いしてるDebianみたいなディストリ使ってると、ただ単純に動かすだけでも一苦労
ついでにいっとくと、cmake_minimum_requiredみたいなイカレたディレクティブ名からお察しできるように
VBAでもリスペクトしてんのかっていうくらい、全てのディレクティブが無駄にバカ長い
include_directories(${CMAKE_CURRENT_SOURCE_DIR}) とか
add_subdirectory(${PROJECT_SOURCE_DIR})とか
AUX_SOURCE_DIRECTORY()とか
set_target_properties()とか
target_include_directories()とか
ディレクトリ追加する如きでも一々 add_subdirectory()
if文ひとつとっても if (HOGEHOGE) ... endif (HOGEHOGE)
変数ひとつ作るだけでこれ → set(CMAKE_CXX_FLAGS "-march=native -O3 -std=gnu++14" CACHE INTERNAL description FORCE)
cmake作者にはネーミングセンス及びエレガントさが致命的に欠けている
他人が書いたCMakeFile.txt利用するだけならまだしも自分で常用するには忍耐が必要
まともな神経してたら喜ぶようなことではない
Re: (スコア:0)
CMakeFile.txt じゃなくて、もっと長い CMakeFiles.txt だよね
Re: (スコア:0)
たぶん同意する人は少数だよ。今時autoconfの暗号めいたキーワードを喜ぶのは独りよがりなオタクだけ。
今は冗長でも覚えやすいキーワードにするのが主流。
UNIXシェル環境でも、最近のCLIツールは比較的長いコマンドが多くなっている(gitのサブコマンドシステムなど)。
その考え方を一貫して適用したのがWindowsのPowerShellという新しいシェル環境で、
すべてのコマンドやオプションが一貫した命名規則に従っている。
実に覚えやすく、ヘルプを見る回数が圧倒的に少ない。
新しいコマンドの習熟もあっという間だし、しばらく使っていなかったコマンドの使い方も忘れにくい。
Re: (スコア:0)
省略名だと、変に寿命長いモノの場合「その名前は既に使われてます」で後半になると被ってハマるから、PowerShell的な規則の方が無難だなとは思ってる。
かと言って古い奴は一文字でも減らして消費量減らそうという面もあったからなぁ。。
Re: (スコア:0)
フルネームで記述するのが最終解なのだろうと信じつつ、
しかしやはりそのルールでコードを書いていると、
識別名が果てしなく長大化することがあって、それはそれで悩む。
(lintツールに関数名が長すぎると怒られて思わず唸った事も...)
directoryとdirの混在にも若干の葛藤が見受けられる。
解読容易なら長い分にはセーフ、という思想は、
10年後にはもう一度再考されたルールが主流になってるかもしれない、とも思う。
(略記の辞書定義記述が標準化される、とか)
Re: (スコア:0)
実に覚えやすく、ヘルプを見る回数が圧倒的に少ない。
新しいコマンドの習熟もあっという間だし、しばらく使っていなかったコマンドの使い方も忘れにくい。
嘘だ、ちっとも覚えられないよ、あれ。
挙句に結果がオブジェクトだから、その仕様まで覚えてないとつらい。
shで書く方がまだ覚えられる。おぼえなければならない量が全然違うもの。
そりゃ日々なにがしかps書いてりゃ覚えられるだろうが、たまにしか書かないならヘルプやエディタの支援がなければ無理。
ありゃエディタの支援有りきだよ。その分強力になってるんだから。
Re: (スコア:0)
自分も覚えやすいと言うにはちょっと引っ掛かる…がUNIXのコマンド系に比べればマシと言えばそれはそれで合ってる気もする。
オブジェクトだからねー、.NET書いた経験があれば馴染むのは早いんだけど、そうでなきゃゼロスタートだよね。
FileとStringの主要プロパティは丸暗記、gmやらhelpやら%と?と|と演算子基礎文法知識そろった辺りからPowerが感じられるようになって、
ある程度落とし穴をクリアするともう手放せなくなる、やれやれ遠いな。
ただいきなり難しい作業をやろうとせず、できる事を増やしていく習熟法では見返りが大きい環境だと思う。
エディタはスクリプトを書く時にしか使わないな。コンソールでパラメータのenumまで補完されるようになってからはラクになった。
そのうちヘルプ情報もコンソール上で自動表示されるようになる気がする。