autoconfの場合、基礎的な仕組みとad hoc なルールが明確に切り分けられてて、 後者はすべてマクロで構築されてるので、足りない部分は既存のマクロを参考に自分で用意するとか容易だけど、 CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、 CMakeであらかじめ対応しているプラットフォーム向けは簡単な記述で済むし実行速度も速いけど、 ちょっと想定から外れた使い方しようとすると途端に面倒くさくなって落差が激しい感じ。
よく知らない頃は ad hoc なルールの類は全部組み込みスクリプティング言語で書いてあるかと思ってたら 全然そうじゃないので、なんかコレジャナイ感が。
CMake (スコア:1)
CMakeホントにいいかなあ。
autoconfの場合、基礎的な仕組みとad hoc なルールが明確に切り分けられてて、
後者はすべてマクロで構築されてるので、足りない部分は既存のマクロを参考に自分で用意するとか容易だけど、
CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、
CMakeであらかじめ対応しているプラットフォーム向けは簡単な記述で済むし実行速度も速いけど、
ちょっと想定から外れた使い方しようとすると途端に面倒くさくなって落差が激しい感じ。
よく知らない頃は ad hoc なルールの類は全部組み込みスクリプティング言語で書いてあるかと思ってたら
全然そうじゃないので、なんかコレジャナイ感が。
Re: (スコア:0)
>CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、
それはCMakeは関係ない。クロスプラットフォームなコードを書くときに、ビルドするのに特定のツールに依存してヘッダーなりソースコードを生成してそれを参照してビルドというのが嫌われているだけ。
それにVisualStudio の各バージョン対応のようなものをスクリプトで前処理する方が数倍めんどくさいと思うが、そういう事やったことあって言ってる?
Re: (スコア:0)
>>CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、
>
> それはCMakeは関係ない。クロスプラットフォームなコードを書くときに、ビルドするのに特定のツールに依存してヘッダーなりソースコードを生成してそれを参照してビルドというのが嫌われているだけ。
「ビルドするのに特定のツールに依存してヘッダーなりソースコードを生成してそれを参照してビルド」の
「特定のツール」って何のこと?
autoconf の場合、配布されたソースをビルドするのに autoconf を含め特定のツールは必要ないと思うんだけど。
まあ UNIX互
Re: (スコア:0)
え?config.h的なものを生成してビルドすることを言っててるんだと思ったんだが違うのか?
>VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて
というのが何を指してるのかわからん。Generatorの話ならVisual Studioは大抵古いバージョンのを指定してソリューション生成しても新しいバージョンで開いてビルド出来るし、IDE必要ないならMakefile生成して好きなコンパイラ使えばいいし。
Makefileしか生成出来ないautoconfと何を比べてるのか解らん
Re: (スコア:0)
> え?config.h的なものを生成してビルドすることを言っててるんだと思ったんだが違うのか?
違いますね。
config.h は、-DHAVE_機能 というコマンドラインオプションを生成しているようなものなので
全然問題ないでしょう。
>> VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて
>
> というのが何を指してるのかわからん。Generatorの話なら...
Generator の話です。
こういう特定のツールに依存した機能を、プラグインとして分離せず CMake 本体に組み込んじゃうセンスがついていけないって話。
Re: (スコア:0)
CMakeがVisualStudioに対応してるんだから
それを本体に組み込もうがプラグインにしようが
それはCMakeの勝手じゃないの?
Re: (スコア:0)
> それを本体に組み込もうがプラグインにしようが
> それはCMakeの勝手じゃないの?
もちろん CMake の勝手なんだけど、そこは最初からプラグインとして外に出しておいた方が設計として筋がいいと思うって話。
VisualStudio じゃなくて別の開発ツールに対して同じような機能つけたくなることもあるのに、
同じようなことするのに CMake 本体側をいじる方が簡単になるような設計方針はちょっと微妙なセンスなんじゃないかってこと。
Re: (スコア:0)
>VisualStudio じゃなくて別の開発ツールに対して同じような機能つけたくなることもあるのに
autoconfに対してmakeじゃなくてじゃなくて「別の開発ツールに対して同じような機能つけたくなること」はないの?なんでCMakeにだけそれを求めるの?
Re: (スコア:0)
> autoconfに対してmakeじゃなくてじゃなくて「別の開発ツールに対して同じような機能つけたくなること」はないの?なんでCMakeにだけそれを求めるの?
autoconf は make 以外のツールに使うこともできます。
autotools は、autoconf と automake と libtool が主な構成要素で、
このうち make を前提しているのは automake だけです。
autoconf を Makefile ではない他のビルドツール生成に使うってのは普通にできます。
こういう機能分割とカスタマイズ・ポイントの提供という意味で、
autotools は良くできてますよ。
CMake の方は VisualStudio だけのためのツ
Re:CMake (スコア:0)
>そういうカスタマイズしたいようなポイント
いうほどそんなところカスタマイズしたいと思わないと思うんだけど・・・
新規でビルドツールを作る人ってかなり少数派だと思うぞ。一番最近でそれなりに使われてるのNinjaぐらいでしょ。
Re: (スコア:0)
> いうほどそんなところカスタマイズしたいと思わないと思うんだけど・・・
> 新規でビルドツールを作る人ってかなり少数派だと思うぞ。一番最近でそれなりに使われてるのNinjaぐらいでしょ。
ビルドツールを作りたいって話じゃないです。
CMake がサポートしていないマイナーな IDE やビルドツールを使いたいって話です。
Re: (スコア:0)
>CMake がサポートしていないマイナーな IDE やビルドツールを使いたい
ってことが言うほど無いって言ってるんですが。
それにAutotools使ったらそれらを簡単に使えるんでしょうか?
Re: (スコア:0)
> ってことが言うほど無いって言ってるんですが。
多い少ないとかいう問題ではなくて、CMake の設計方針が微妙って話をしてます。
> それにAutotools使ったらそれらを簡単に使えるんでしょうか
無理です。
CMake の方が新しいし機能が多いのは明らかです。
で、新しいんだから、設計も優れてると期待して使い始めたら、そこはそうでもなかったなという話です。
Re: (スコア:0)
そういう話なら分からなくもないです。autoconfの方がカスタマイズ性が優れてるみたいな言ってるように見えたので、何言ってるんだとしか思えなかったもので。今ならmasonの方が良い!とかならツッコミ入れなかったんですが。
ただ、使う方としては内部設計がどうであろうがあまり関係ないんですよね。マイナーなビルドツールでしかビルド出来ないターゲットが存在するのであれば、さっさとそれは捨ててmakeやninjaなどでビルドできるようにしたほうがよほど生産的です。特にクロスプラットフォームなソフトウェアに使用するのであれば。
gccやclangベースの(もしくは同等のオプションが使用できる)コンパイラを使用するのであれば、CMakeのツー