パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

GnuPG2のフォーク「NeoPG」、開発中」記事へのコメント

  • by Anonymous Coward

    CMakeホントにいいかなあ。

    autoconfの場合、基礎的な仕組みとad hoc なルールが明確に切り分けられてて、
    後者はすべてマクロで構築されてるので、足りない部分は既存のマクロを参考に自分で用意するとか容易だけど、
    CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、
    CMakeであらかじめ対応しているプラットフォーム向けは簡単な記述で済むし実行速度も速いけど、
    ちょっと想定から外れた使い方しようとすると途端に面倒くさくなって落差が激しい感じ。

    よく知らない頃は ad hoc なルールの類は全部組み込みスクリプティング言語で書いてあるかと思ってたら
    全然そうじゃないので、なんかコレジャナイ感が。

    • by Anonymous Coward

      >CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、

      それはCMakeは関係ない。クロスプラットフォームなコードを書くときに、ビルドするのに特定のツールに依存してヘッダーなりソースコードを生成してそれを参照してビルドというのが嫌われているだけ。

      それにVisualStudio の各バージョン対応のようなものをスクリプトで前処理する方が数倍めんどくさいと思うが、そういう事やったことあって言ってる?

      • by Anonymous Coward

        >>CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、
        >
        > それはCMakeは関係ない。クロスプラットフォームなコードを書くときに、ビルドするのに特定のツールに依存してヘッダーなりソースコードを生成してそれを参照してビルドというのが嫌われているだけ。

        「ビルドするのに特定のツールに依存してヘッダーなりソースコードを生成してそれを参照してビルド」の
        「特定のツール」って何のこと?
        autoconf の場合、配布されたソースをビルドするのに autoconf を含め特定のツールは必要ないと思うんだけど。
        まあ UNIX互

        • by Anonymous Coward on 2018年01月06日 1時58分 (#3340408)

          え?config.h的なものを生成してビルドすることを言っててるんだと思ったんだが違うのか?
          >VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて

          というのが何を指してるのかわからん。Generatorの話ならVisual Studioは大抵古いバージョンのを指定してソリューション生成しても新しいバージョンで開いてビルド出来るし、IDE必要ないならMakefile生成して好きなコンパイラ使えばいいし。
          Makefileしか生成出来ないautoconfと何を比べてるのか解らん

          親コメント
          • by Anonymous Coward

            > え?config.h的なものを生成してビルドすることを言っててるんだと思ったんだが違うのか?

            違いますね。
            config.h は、-DHAVE_機能 というコマンドラインオプションを生成しているようなものなので
            全然問題ないでしょう。

            >> VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて
            >
            > というのが何を指してるのかわからん。Generatorの話なら...

            Generator の話です。
            こういう特定のツールに依存した機能を、プラグインとして分離せず CMake 本体に組み込んじゃうセンスがついていけないって話。

            • by Anonymous Coward

              特定のツール(Make)だけに依存したautoconfを持ち上げてそう言われてもなあ…

              • by Anonymous Coward

                > 特定のツール(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 が当初の目標を越えて成功しすぎたせい。

            • by Anonymous Coward

              CMakeがVisualStudioに対応してるんだから
              それを本体に組み込もうがプラグインにしようが
              それはCMakeの勝手じゃないの?

              • by Anonymous Coward

                > それを本体に組み込もうがプラグインにしようが
                > それはCMakeの勝手じゃないの?

                もちろん CMake の勝手なんだけど、そこは最初からプラグインとして外に出しておいた方が設計として筋がいいと思うって話。
                VisualStudio じゃなくて別の開発ツールに対して同じような機能つけたくなることもあるのに、
                同じようなことするのに CMake 本体側をいじる方が簡単になるような設計方針はちょっと微妙なセンスなんじゃないかってこと。

              • by Anonymous Coward

                >VisualStudio じゃなくて別の開発ツールに対して同じような機能つけたくなることもあるのに
                autoconfに対してmakeじゃなくてじゃなくて「別の開発ツールに対して同じような機能つけたくなること」はないの?なんでCMakeにだけそれを求めるの?

              • by Anonymous Coward

                > autoconfに対してmakeじゃなくてじゃなくて「別の開発ツールに対して同じような機能つけたくなること」はないの?なんでCMakeにだけそれを求めるの?

                autoconf は make 以外のツールに使うこともできます。
                autotools は、autoconf と automake と libtool が主な構成要素で、
                このうち make を前提しているのは automake だけです。
                autoconf を Makefile ではない他のビルドツール生成に使うってのは普通にできます。
                こういう機能分割とカスタマイズ・ポイントの提供という意味で、
                autotools は良くできてますよ。

                CMake の方は VisualStudio だけのためのツ

              • by Anonymous Coward

                >autoconf を Makefile ではない他のビルドツール生成に使うってのは普通にできます。
                そうなんですね。ググってもすぐ見つかりませんでしたが、例えばどのようなものがあるのでしょうか?

              • by Anonymous Coward

                >そういうカスタマイズしたいようなポイント
                いうほどそんなところカスタマイズしたいと思わないと思うんだけど・・・
                新規でビルドツールを作る人ってかなり少数派だと思うぞ。一番最近でそれなりに使われてるのNinjaぐらいでしょ。

              • by Anonymous Coward

                > そうなんですね。ググってもすぐ見つかりませんでしたが、例えばどのようなものがあるのでしょうか?

                make は普遍的に存在していて、ニーズが少ないから見つからないでしょうね。

                autoconf っていうのは、本質的には m4 マクロを使ってシェルスクリプトを生成するツールに過ぎず、
                その m4 マクロとして、システム付属のヘッダファイルやライブラリを参照した結果に応じて
                テンプレートをベースにファイルを生成する仕組みが完備しているというものです。

                このコアの仕組みには make への依存はまったくありません。
                生成するファイルも Makefile とは限らず、configure.ac で逐一指定するようになってます。
                デフォルトで用意されているマクロに automake 用のものが沢山用意されていて、
                普通は au

              • by Anonymous Coward

                > いうほどそんなところカスタマイズしたいと思わないと思うんだけど・・・
                > 新規でビルドツールを作る人ってかなり少数派だと思うぞ。一番最近でそれなりに使われてるのNinjaぐらいでしょ。

                ビルドツールを作りたいって話じゃないです。
                CMake がサポートしていないマイナーな IDE やビルドツールを使いたいって話です。

              • by Anonymous Coward

                >CMake がサポートしていないマイナーな IDE やビルドツールを使いたい
                ってことが言うほど無いって言ってるんですが。
                それにAutotools使ったらそれらを簡単に使えるんでしょうか?

              • by Anonymous Coward

                普遍的に存在しているmakeへの出力をcmakeも対応してるんですが、Ninjaなどのビルドツールへの対応もされてますよね。そこには需要があるからです。

                なぜautoconfでNinja対応が見つからないのでしょうか?貴方が言うように普通にできてカスタマイズポイントの提供が出来ているというのであれば、そのカスタマイズポイントを使って提供されていると思うんですが。
                まさかautotoolsのようなメジャーなツールをNinjaチームが対応可能なのにあえて無視するとは思えません。

                https://github.com/ninja-build/ninja/wiki/List-of-generators-producing... [github.com]

              • by Anonymous Coward

                > ってことが言うほど無いって言ってるんですが。

                多い少ないとかいう問題ではなくて、CMake の設計方針が微妙って話をしてます。

                > それにAutotools使ったらそれらを簡単に使えるんでしょうか

                無理です。
                CMake の方が新しいし機能が多いのは明らかです。
                で、新しいんだから、設計も優れてると期待して使い始めたら、そこはそうでもなかったなという話です。

              • by Anonymous Coward

                > なぜautoconfでNinja対応が見つからないのでしょうか?

                目的が違うからでしょうね。
                autoconf の目的は、より多くの UNIX系 OS で容易にソフトウェアをビルドすることです。
                だから autoconf を利用したソースコードをビルドする際に必要なのは、
                UNIX系OSで標準的に付属しているツール類とツールチェインだけです。
                ビルドする側では、autoconf のような余分なソフトウェアをあらかじめ入れておく必要はありません。

                このように、CMake や ninja のようなツールを用意しなくてもビルドが行えるという利点の裏返しとし

              • by uxi (5376) on 2018年01月08日 1時57分 (#3341021)

                本当、Autotools を使って make 以外でビルドしてる例って凄いレアケースだと思う。
                上で挙げられてる cccl も CL.EXE を cc 互換にする wrapper (つまり make を利用してる)だし、少なくとも自分は make 以外の事例を例を見たことがない。

                たいへん興味があるので、もしも知っているプロジェクトがあるなら、後学のために例示して頂けると嬉しい。

                --
                uxi
                親コメント
              • by Anonymous Coward

                そういう話なら分からなくもないです。autoconfの方がカスタマイズ性が優れてるみたいな言ってるように見えたので、何言ってるんだとしか思えなかったもので。今ならmasonの方が良い!とかならツッコミ入れなかったんですが。

                ただ、使う方としては内部設計がどうであろうがあまり関係ないんですよね。マイナーなビルドツールでしかビルド出来ないターゲットが存在するのであれば、さっさとそれは捨ててmakeやninjaなどでビルドできるようにしたほうがよほど生産的です。特にクロスプラットフォームなソフトウェアに使用するのであれば。
                gccやclangベースの(もしくは同等のオプションが使用できる)コンパイラを使用するのであれば、CMakeのツー

犯人はmoriwaka -- Anonymous Coward

処理中...