アカウント名:
パスワード:
そいつと心中するつもりでインストールしたりプロジェクトを作ったりする必要のあるものばっか。
なんか、人には「田舎の景色とか思いでとか、要らないものは捨てなよ、都会に集まってもっと身軽になりなよｗ」とか言っときながらシリコンの中となると全然できてない奴多いよな。ムカつく。
なんでたがたビルドツールを「インストール」する必要があるわけ？7z解凍したらすぐ動けよ。ムカつく。
クサす先を間違えているんじゃないかな、と。
問題は、ソフトウェアパッケージにあるんじゃありませんよ。 標準的なビルドツールがない (あるいは OS なり開発環境なりに添付されていない) ことに起因するんです。
まずは歴史的な経緯から。
1980年代〜1990年代アタマくらいまでは、ビルド用の Makefile とか *.bat とかを添付してくれて、ダウンロードしたら大体そのままビルドできるよう意図されたオンラインソフトが結構あったのですが、それって「貴殿の開発環境も俺様と同じ」前提なわけです (そして C とか使ってると、そんなの殆ど成り立ちません。 例えば「X.h ってどこにある？」 「/usr/include/X11? /usr/X11R5/include? /usr/dt/include? /usr/openwin/include?」とか。 あるいは「お前さんの OS、unistd.h あるんだっけ？ それとも dos.h 使えばいいんだっけ？」とか。 あるいは「俺様のコンパイラは lcc.exe なのであるが、貴様のは cl.exe であるか tcc.exe であるか」とかとかとか。 時代が下って Java とかスクリプト言語だと環境の違いは比較的マシになるのですが)。 その結果、imake が出来たり、configure が付くようになったり、色々したりして今に至るというわけです。
それに、Windows 向けの開発ならどうせ Visual Studio と心中することになるでしょう (え、embarcadero [embarcadero.com] ですか？ 敢えてそんなの使ってるなら自力で何とかできる人でしょ？)。 Unices 向けの開発なら最低限 make を使えることが分かっているので、可搬性を重視するなら make を使うか Makefile を吐き出す何かを使うようなパッケージにするでしょう。 実際、それが多数派です (まあ、たまに Jam 使ったりする例 [boost.org]もあるけど)。
なので、「ダウンロードしてすぐビルドできない」なんてのは、1990年代後半には少数派になりつつあったのです。 ところが、その前後に Java が流行るようになると、また少し状況が変わって来ます。
Java には「これが決定版」と言えるビルドツールがなく (敢えて言うと ant [apache.org] が近いかな)、開発側がワリと自分の好みで選択できる、群雄割拠状態になってしまいました。 まぁ、Java のウリは「一度書けばどこでも動く」なので、「そもそもビルドが面倒とか言う奴がソースコードなんかダウンロードするなよ。バイナリそのまま動かせばいいじゃん」と言えてしまうのですが。
# そういう意味では、ソースコードだけリリースしてバイナリを # リリースしないソフトウェアプロジェクトに対しては、 # 「Java の利点を生かしてない」と文句を言えるかも知れない。
JDK に標準 (必要最低限度の) ビルドツール付けてくれればいいのにね、OpenJDK [java.net] とかどうしてるのかな、と思ったら「make 使え [java.net]。 え、Windows なんか使ってんの？ Cygwin [cygwin.com] か MinGW [mingw.org] で代替すりゃいいだろ」ですか、そうですか...
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
どれもこれも気に入らないんだよなあ (スコア:0)
そいつと心中するつもりで
インストールしたりプロジェクトを作ったりする必要のあるものばっか。
なんか、人には「田舎の景色とか思いでとか、要らないものは捨てなよ、都会に集まってもっと身軽になりなよｗ」とか言っときながら
シリコンの中となると全然できてない奴多いよな。
ムカつく。
なんでたがたビルドツールを「インストール」する必要があるわけ？
7z解凍したらすぐ動けよ。
ムカつく。
Re:どれもこれも気に入らないんだよなあ (スコア:1)
クサす先を間違えているんじゃないかな、と。
問題は、ソフトウェアパッケージにあるんじゃありませんよ。 標準的なビルドツールがない (あるいは OS なり開発環境なりに添付されていない) ことに起因するんです。
まずは歴史的な経緯から。
1980年代〜1990年代アタマくらいまでは、ビルド用の Makefile とか *.bat とかを添付してくれて、ダウンロードしたら大体そのままビルドできるよう意図されたオンラインソフトが結構あったのですが、それって「貴殿の開発環境も俺様と同じ」前提なわけです (そして C とか使ってると、そんなの殆ど成り立ちません。 例えば「X.h ってどこにある？」 「/usr/include/X11? /usr/X11R5/include? /usr/dt/include? /usr/openwin/include?」とか。 あるいは「お前さんの OS、unistd.h あるんだっけ？ それとも dos.h 使えばいいんだっけ？」とか。 あるいは「俺様のコンパイラは lcc.exe なのであるが、貴様のは cl.exe であるか tcc.exe であるか」とかとかとか。 時代が下って Java とかスクリプト言語だと環境の違いは比較的マシになるのですが)。 その結果、imake が出来たり、configure が付くようになったり、色々したりして今に至るというわけです。
それに、Windows 向けの開発ならどうせ Visual Studio と心中することになるでしょう (え、embarcadero [embarcadero.com] ですか？ 敢えてそんなの使ってるなら自力で何とかできる人でしょ？)。 Unices 向けの開発なら最低限 make を使えることが分かっているので、可搬性を重視するなら make を使うか Makefile を吐き出す何かを使うようなパッケージにするでしょう。 実際、それが多数派です (まあ、たまに Jam 使ったりする例 [boost.org]もあるけど)。
なので、「ダウンロードしてすぐビルドできない」なんてのは、1990年代後半には少数派になりつつあったのです。 ところが、その前後に Java が流行るようになると、また少し状況が変わって来ます。
Java には「これが決定版」と言えるビルドツールがなく (敢えて言うと ant [apache.org] が近いかな)、開発側がワリと自分の好みで選択できる、群雄割拠状態になってしまいました。 まぁ、Java のウリは「一度書けばどこでも動く」なので、「そもそもビルドが面倒とか言う奴がソースコードなんかダウンロードするなよ。バイナリそのまま動かせばいいじゃん」と言えてしまうのですが。
# そういう意味では、ソースコードだけリリースしてバイナリを
# リリースしないソフトウェアプロジェクトに対しては、
# 「Java の利点を生かしてない」と文句を言えるかも知れない。
JDK に標準 (必要最低限度の) ビルドツール付けてくれればいいのにね、OpenJDK [java.net] とかどうしてるのかな、と思ったら「make 使え [java.net]。 え、Windows なんか使ってんの？ Cygwin [cygwin.com] か MinGW [mingw.org] で代替すりゃいいだろ」ですか、そうですか...