autoconfの場合、基礎的な仕組みとad hoc なルールが明確に切り分けられてて、 後者はすべてマクロで構築されてるので、足りない部分は既存のマクロを参考に自分で用意するとか容易だけど、 CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、 CMakeであらかじめ対応しているプラットフォーム向けは簡単な記述で済むし実行速度も速いけど、 ちょっと想定から外れた使い方しようとすると途端に面倒くさくなって落差が激しい感じ。
よく知らない頃は ad hoc なルールの類は全部組み込みスクリプティング言語で書いてあるかと思ってたら 全然そうじゃないので、なんかコレジャナイ感が。
makeはUNIXでは普遍的に存在しているし、 UNIX どころかごくマイナーな OS でも互換実装があるし、 もちろん Windows にもあるし Visual Studio にもついてくるし、 それどころか MS-DOS の頃だって互換実装があったし、 autoconf (autotools) は UNIX version 7 の頃からある make の機能にしか依存してないわけで、 そんなの問題にする方がおかしいって感じ。
CMake (スコア:1)
CMakeホントにいいかなあ。
autoconfの場合、基礎的な仕組みとad hoc なルールが明確に切り分けられてて、
後者はすべてマクロで構築されてるので、足りない部分は既存のマクロを参考に自分で用意するとか容易だけど、
CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、
CMakeであらかじめ対応しているプラットフォーム向けは簡単な記述で済むし実行速度も速いけど、
ちょっと想定から外れた使い方しようとすると途端に面倒くさくなって落差が激しい感じ。
よく知らない頃は ad hoc なルールの類は全部組み込みスクリプティング言語で書いてあるかと思ってたら
全然そうじゃないので、なんかコレジャナイ感が。
Re: (スコア:0)
>CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、
それはCMakeは関係ない。クロスプラットフォームなコードを書くときに、ビルドするのに特定のツールに依存してヘッダーなりソースコードを生成してそれを参照してビルドというのが嫌われているだけ。
それにVisualStudio の各バージョン対応のようなものをスクリプトで前処理する方が数倍めんどくさいと思うが、そういう事やったことあって言ってる?
Re:CMake (スコア:0)
>>CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、
>
> それはCMakeは関係ない。クロスプラットフォームなコードを書くときに、ビルドするのに特定のツールに依存してヘッダーなりソースコードを生成してそれを参照してビルドというのが嫌われているだけ。
「ビルドするのに特定のツールに依存してヘッダーなりソースコードを生成してそれを参照してビルド」の
「特定のツール」って何のこと?
autoconf の場合、配布されたソースをビルドするのに autoconf を含め特定のツールは必要ないと思うんだけど。
まあ UNIX互換なシェルとコマンド群は必要だけど。
CMake の場合、ビルドするのに、配布側が想定しているのと同じかより新しいバージョンの
CMake を用意する必要があるわけで、「特定のツールに依存」しているのは、
むしろ CMake な気がする。
> それにVisualStudio の各バージョン対応のようなものをスクリプトで前処理する方が数倍めんどくさいと思うが、そういう事やったことあって言ってる?
まあ autoconf で VisualStudio 使う時は、 https://github.com/swig/cccl [github.com] 入れるだけで済む程度の
ことしかしてないから、あまり苦労するような経験自体をしてないかなあ。
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)
特定のツール(Make)だけに依存したautoconfを持ち上げてそう言われてもなあ…
Re: (スコア:0)
> 特定のツール(Make)だけに依存したautoconfを持ち上げてそう言われてもなあ…
makeはUNIXでは普遍的に存在しているし、
UNIX どころかごくマイナーな OS でも互換実装があるし、
もちろん Windows にもあるし Visual Studio にもついてくるし、
それどころか MS-DOS の頃だって互換実装があったし、
autoconf (autotools) は UNIX version 7 の頃からある make の機能にしか依存してないわけで、
そんなの問題にする方がおかしいって感じ。
それよりは Bourne shell その他の UNIXツール群に依存している方を問題にした方がいいと思うけど。
もっとも autoconf は当初 UNIX系 OS しかターゲットにしてなかったから、autoconf が悪いわけではない。
これが問題になるのは autoconf が当初の目標を越えて成功しすぎたせい。
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: (スコア:0)
>autoconf を Makefile ではない他のビルドツール生成に使うってのは普通にできます。
そうなんですね。ググってもすぐ見つかりませんでしたが、例えばどのようなものがあるのでしょうか?
Re: (スコア:0)
>そういうカスタマイズしたいようなポイント
いうほどそんなところカスタマイズしたいと思わないと思うんだけど・・・
新規でビルドツールを作る人ってかなり少数派だと思うぞ。一番最近でそれなりに使われてるのNinjaぐらいでしょ。
Re: (スコア:0)
> そうなんですね。ググってもすぐ見つかりませんでしたが、例えばどのようなものがあるのでしょうか?
make は普遍的に存在していて、ニーズが少ないから見つからないでしょうね。
autoconf っていうのは、本質的には m4 マクロを使ってシェルスクリプトを生成するツールに過ぎず、
その m4 マクロとして、システム付属のヘッダファイルやライブラリを参照した結果に応じて
テンプレートをベースにファイルを生成する仕組みが完備しているというものです。
このコアの仕組みには make への依存はまったくありません。
生成するファイルも Makefile とは限らず、configure.ac で逐一指定するようになってます。
デフォルトで用意されているマクロに automake 用のものが沢山用意されていて、
普通は au
Re: (スコア:0)
> いうほどそんなところカスタマイズしたいと思わないと思うんだけど・・・
> 新規でビルドツールを作る人ってかなり少数派だと思うぞ。一番最近でそれなりに使われてるのNinjaぐらいでしょ。
ビルドツールを作りたいって話じゃないです。
CMake がサポートしていないマイナーな IDE やビルドツールを使いたいって話です。
Re: (スコア:0)
>CMake がサポートしていないマイナーな IDE やビルドツールを使いたい
ってことが言うほど無いって言ってるんですが。
それにAutotools使ったらそれらを簡単に使えるんでしょうか?
Re: (スコア:0)
普遍的に存在しているmakeへの出力をcmakeも対応してるんですが、Ninjaなどのビルドツールへの対応もされてますよね。そこには需要があるからです。
なぜautoconfでNinja対応が見つからないのでしょうか?貴方が言うように普通にできてカスタマイズポイントの提供が出来ているというのであれば、そのカスタマイズポイントを使って提供されていると思うんですが。
まさかautotoolsのようなメジャーなツールをNinjaチームが対応可能なのにあえて無視するとは思えません。
https://github.com/ninja-build/ninja/wiki/List-of-generators-producing... [github.com]
Re: (スコア:0)
> ってことが言うほど無いって言ってるんですが。
多い少ないとかいう問題ではなくて、CMake の設計方針が微妙って話をしてます。
> それにAutotools使ったらそれらを簡単に使えるんでしょうか
無理です。
CMake の方が新しいし機能が多いのは明らかです。
で、新しいんだから、設計も優れてると期待して使い始めたら、そこはそうでもなかったなという話です。
Re: (スコア:0)
> なぜautoconfでNinja対応が見つからないのでしょうか?
目的が違うからでしょうね。
autoconf の目的は、より多くの UNIX系 OS で容易にソフトウェアをビルドすることです。
だから autoconf を利用したソースコードをビルドする際に必要なのは、
UNIX系OSで標準的に付属しているツール類とツールチェインだけです。
ビルドする側では、autoconf のような余分なソフトウェアをあらかじめ入れておく必要はありません。
このように、CMake や ninja のようなツールを用意しなくてもビルドが行えるという利点の裏返しとし
Re:CMake (スコア:2)
本当、Autotools を使って make 以外でビルドしてる例って凄いレアケースだと思う。
上で挙げられてる cccl も CL.EXE を cc 互換にする wrapper (つまり make を利用してる)だし、少なくとも自分は make 以外の事例を例を見たことがない。
たいへん興味があるので、もしも知っているプロジェクトがあるなら、後学のために例示して頂けると嬉しい。
uxi
Re: (スコア:0)
そういう話なら分からなくもないです。autoconfの方がカスタマイズ性が優れてるみたいな言ってるように見えたので、何言ってるんだとしか思えなかったもので。今ならmasonの方が良い!とかならツッコミ入れなかったんですが。
ただ、使う方としては内部設計がどうであろうがあまり関係ないんですよね。マイナーなビルドツールでしかビルド出来ないターゲットが存在するのであれば、さっさとそれは捨ててmakeやninjaなどでビルドできるようにしたほうがよほど生産的です。特にクロスプラットフォームなソフトウェアに使用するのであれば。
gccやclangベースの(もしくは同等のオプションが使用できる)コンパイラを使用するのであれば、CMakeのツー