本当の一因は、本来手書きでも簡単な Makefile の作成をわざわざ難しくしてしま
う autotools を権威に流されたのか多くのプロジェクトが使ってしまっている事にある。
高々 Makefile 1つ作るためにも以下のような工程を踏まなければならない。
本来、典型的には、ソースファイルである *.c, *.cxx, *.cpp を指定するだけ
でも自動生成する事が出来るはずなのに、ツール類が馬鹿だからそうなってない。
なのに、「Linuxはプログラマーには便利」などと嘘情報が流れるから、普及しない。
しかも、カレントディレクトリのスクリプトの実行に「./configure」などと「./」
の指定が必要なのも馬鹿丸出し。ファイル名に大文字小文字の区別がされているのも馬鹿。
ファイルのコピーもdosなら、「copy *.c /xxx/aaa 」で済むことが
$ find . -name '*.c' | xargs -n 1 -i cp -p {} /xxx/aaa
などとしなくてはならず長すぎ、馬鹿ですか？ しかも、'*.c'の部分が、*.c と書かれている
説明が溢れているがそれだとbashが展開してしまうのでたまたま上手く行く事はあっても、
実際には正しくない。また、mountしないとディスクが認識出来ないのも初代PC-8001の
レベル。PC-8801で自動マウントできるようになったのに（いつの時代（苦笑））。まずは、
不便さを認めるなければ、改善すらままならないのにそれすら全否定。正直に便利と思って
るなら井の中の蛙で馬鹿で無知なだけだ。そして、僅か１点でも間違いがあれば全てが間違って
いるように全否定してしまうLinux信奉者の愚かさもアホとしか言いようがない。
01. (Makefile.amの作成) # 手作業
02. $ autoscan
03. [configure.scan生成] # 自動
04. $ cp configure.scan configure.ac
05. (configure.acの修正） # 手作業
06. $ aclocal
07. $ automake -a
08. [Makefile.in生成] # 自動
09. $ autoheader
10. [config.h.in生成] # 自動
11. $ autoconf
12. [configure生成] # 自動
13. $ ./configure実行
14. [Makefile生成] # 自動
時間をかけ苦労して使っている。そして大量の時間と膨大なHDD容量と、
ネット容量を使いまくって、それしかやる事が無い無能連中がOSS開発で
よってたかって、なんとか表面的には動くバグだらけの使えないツール類を
作りまくって出来上がった集大成が Linuxだ。
しかもカーネルをビルドできるだけでドヤ顔できるほどの難易度
コーディング中にリアルタイムでエラーが指摘される時代に何やってんだとは思う
他のOSでは macOS High Sierra はちょい品質が…なのだし。
macOsだと糞Xcode
新しく作るものも場当たりの対応に合うように作ることになる切なさがある
そして今は逆に、みんな好き勝手にビルドツールを作る時代になって、それはそれで面倒くさいことに
> ファイルのコピーもdosなら、「copy *.c /xxx/aaa 」で済むことが
できないんだっけ？
Linuxでcp *.c /xxx/aaaするより限界低そうだけどどうなんだろうな
よく知らないGUIのOSだと、モヤモヤする。
copyじゃなく、xcopyかな。
DOSのcommand.comはワイルドカードを展開しない仕様だったからコマンドラインの
文字数制限の壁にかからなかった。一方、Linuxは、普段は cp *.c /xxx/aaa で行け
ても全てのファイル名の合計文字数が長くなればその制限に引っかかる。だから
結局、findを使わざるを得なくなることがある。そしてファイル数が多いときにもエラーを
絶対に起こさないためには最初からfindを使わざるを得ないと思う。じゃあなんのために、
bashのワイルドカード展開はあるかって話になるかも。
知識がついてきてないだけやんｗｗｗｗ
GUIは文化の壁が厚すぎる
OS違ったら当然のこと、業界によっても常識が変わるからな
「この仕様はどんなメリットがあるの?」とか「DOS のこれは Linux ではどうやるの?」とかなら助けてやれるかもしれないのだが。
誰も知らんのか
CMakeなら.slnファイルも作れるという強みはあるが…
しかしはいろいろと誤認や知識不足がみられるな
PATHに.入れればconfigureで実行できるようになるがセキュアでないので
推奨されない
今時のGUI環境ならPnPでディスクは勝手にマウントされる
wildcardの展開をshellまかせにするかコマンド側がよろしくやってくれるのかは
一長一短あるだろう
Visual Studioがいい環境なのは認めるよ。VSCodeはその域に達してないし
>PATHに.入れればconfigureで実行できるようになるがセキュアでないので
>推奨されない
それでバランスしてしまったのがUnix文化の困ったところなんだ。
DOSだと、暗黙のうちに「.」が検索パスに入っていることが前提だからそれを
前提にした文化が形成されたので、その状態でも十分に「セキュア」になった。
その結果、./を付けなくてもカレント・ディレクトリのEXEやBATファイルを実行できる
という超便利な環境となった。ところが、Unixだと古い文化を引きずったまま
直ることが無かったので不便なままとなった。その結果、今後Wineが究極まで
達してもLinuxがWindowsの代わりにはなりえないかも知れない。
>今時のGUI環境ならPnPでディスクは勝手にマウントされる
Ubuntuだけど、
1. /etc/fstab に光学ドライブを書いておくと、Login前に待機状態になってしまう。
2. Login後、メディアを入れてからNautilusでドライブをクリックすると認識はできる。
3. しかし、メディアを交換したときにトラブルが生じやすい。例えば、Wineだ。
4. HDDですら、Nautilusでドライブをクリックせずに、いきなり端末を使った場合には
マウントされてない。
5. おまけをいうと、FAT32のような単純なドライブですら、Linuxではext3とはpermissionなど
で非互換がおきまくって、正しく動作出来ない。たとえば、そのドライブでは、ソースからは
上手くmakeが出来ず、どこかで不具合が生じてしまう。だから、ext3ドライブにソースを
全コピーしないといけなくなる。
>wildcardの展開をshellまかせにするかコマンド側がよろしくやってくれるのかは
>一長一短あるだろう
現実に良く使うコマンドがとても長くなってしまっているのだから、結果的にはLinuxの
方が使いにくい。
>Visual Studioがいい環境なのは認めるよ。
この書き方だと、プログラムの経験が浅い人にはVisual Studio だけが例外的に
「いい環境」なだけだと思われてしまう。
ところが、実際にはそうではなく、TurboC++, WatcomC++なども、十分に便利だった。
コマンドラインでも、gccやgnu make などとくらべて、だいぶ便利だったんだ。
はっきりいえば、gccやmakeやLinux文化は洗練されておらず、頭が悪いんだ。
それより最近は言語に特化したビルドツールが多いから色々覚えなきゃいけないのが面倒
基本的には、make自身の問題よりも書き方やそれ以外の変なツールが標準になっていることの問題
が大きい。しかし、gnu toolsは、余計なメッセージだけを消す事が出来ないことが多いのが
クソなんだ。消そうと思うと全てのメッセージが消えたりして、使い物にならない。turbo c++
や watcom c++ , msc++, vc++のツール類は、どれもそんな初歩的な不具合は無かった。
仕事で嫌々やってる商用ソフトがかなうわけないと思ってたけど、そうでもなかったな。
やっぱり仕事で真剣にやってる人たちにはかなわないんだな。
ただ当時のレベルだったらemacsのmake+ctags環境も十分匹敵する
レベルだったと思うが。あの頃にリファクタリング機能とかなかっただろう。
jetbeansの名前も出てるけど、Eclipse, Anjuta, KDevelopみたいな
IDEもある中でそういうのを出して比較しないのはちょっとフェアじゃ
ないんじゃないか。
まあそれらと比較してもIntelliSenseに及ばないんだけど。
悪意あるユーザーの想定が必要だった。というかWindosが今の状態で
十分セキュアとは思えないんだけど。悪意あるユーザに勝手にファイル
置かれて実行されるリスクは下がっちゃいないのでは。
fstabを書いた例と書かない例を混ぜて文句いうのはちょっと感心しない。
FAT32はそもそもろくなメタデータおけなくてPOSIX的なファイルの扱い
にマッチしないのでそりゃしょうがないよとしかいえない。
全コピーしなくてもloopback filesystem置く手段はある。Windowsでも
似たようなこと(vhdファイル作ってマウント)しないとFAT32領域に
まともにアプリがインストールできない事態起きるし。
そこはもう慣れの問題で自分は「クソ、勝手に処理しやがって」と
思うことの方が多いし味方の別れるところだと思う。個人的にはそんなに
頻繁に使うならエイリアスかスクリプトにでもしたら、と思う。
>全コピーしなくてもloopback filesystem置く手段はある。
こういうのを聞いて、イザやってみても別のところで不具合が起きて時間の無駄になった
経験が沢山ある。
>FAT32はそもそもろくなメタデータおけなくてPOSIX的なファイルの扱い
>にマッチしないのでそりゃしょうがないよとしかいえない。
数学的にはFAT32であってもext3の模倣もする事が出来る。
あなたは数学は苦手ですか？ 苦手なら、数学とプログラムと
UnixとWindowsとExt3とFAT32の全てに詳しい者に聞いてみるといい。
自分にはそれをするための方法が頭の中で分かる。そういうツールや
ドライバが既にあるという意味ではない。作ろうと思えば作れるという
意味。そして、自分にはその義務はない。
統合環境でVSが良いのは認めるけどLinuxだってEclipseやJetbrainはあるし
未だにまともなパッケージ管理もないしシェルは使えないし開発する環境としては最悪だよ
開発環境全般で言えばWindowsだけじゃ不足なのでWSLが持て囃されたりしてるし
万能なものはないからいいとこ取りで使っていればいいだけだ
だから、Linux よりも DOS がいいというのはなかなか興味深い見解だと思ったのだが……どうやらお呼びじゃなさそうだ。
そりゃ、DOSはLinuxのサブセットみたいに普通思い勝ち。でも実際はむしろMSが
進化させたんじゃないかと、今では思ってる。実際MS製Unixは売れずにDOS
だけが売れたし。
コマンドライン・コンパイラを比較してもやはり、TurboC++, WatcomC++などとくらべて
gnu tools は使いにくいと思ってるし、上でもそう書いてる。
別のOSでも同様の手順でいいという使い勝手はTurboCとかじゃ実現できないわけで結局使い易いとかは主観でしかないしどれだけ自分に都合が良いかというだけのこと
色々な嘘によって、ミュンヘン市は損害を追ったのに、Linuxサイドは「技術的な問題じゃない」
という一点張り。スラドではこの態度に対し、「なんと言う言い訳」と言われてた。
最初に手をそめた環境がその人の一生の好みを決めるところがある
自分の好みを言っても主観以外のなにものでもない
LibreOfficeの開発者もそんな事言ってた・・・。
ただ、そんなことしなくても(30年前に比べれば)言語やOSで色々と統一化や
標準化もあったりしたせいか、それらのツールのやり方が本末転倒で意味不明
な存在になってり。
今は、そもそも出来ない場合にはそんなツール使っても出来ないし、出来る
場合には使わなくても出来る。存在意義がどれくらい果たしてあるのか。
今は、「マルチプラットフォーム」での非互換部分を自動的に修正してくれるかどうかの話
やで。
想定されたOSでそれが出来ないということなら問題は人間側に(以下略
16年前に書いたソース群を、今日makeする事ができた。
これ、本当に凄い事だと思う。1回覚えた事や環境がずっと使えるって幸せ。
良書がなかったしね。訳本も酷かった。本当に酷かった。
そもそもポータビリティに気を付けてソースを書きなさい。
後は、色んな環境でもmakeできるようにしてあげるよって思想だった記憶。
お陰でvine2.1.5時代に作った物が今でもmakeできた。
ただ、思い出して修正できるまでに10日かかった。
当時も日本人開発のソフトには導入が不完全で、バグレポート送ったりしてたわ。
ttp://http://www.jaist.ac.jp/~kiyoshiy/memo/autoconf.html >autoconf/automakeのバージョンを少し上げただけで、 それまでに作成した
>configure.inに対してautoconf/automakeを実行すると エラーや警告を生じる
>ようになる場合が多々あります。 むやみに最新バージョンをインストールし
>ないほうがよいようです。
>以降の記述でも、autoconf/automakeのバージョンによってはエラーや警告
>が発生する場合があります。
片方の環境しかなければ、もう片方のテストはしないってことだよね。
#ifdef HAVE_GETCWD
getcwd(pathname, sizeof(pathname));
#else
# ifdef HAVE_GETWD
getwd(pathname);
# endif
#endif
このようなコードを何回も書くのは駄目コードだ。なぜなら、1文字でも間違って
いればバグるのに、テストも出来ないから。
#ifdef HAVE_GETCVD
#ifdef _HAVE_GETCWD
#ifdef HAVE_GET_CWD
#ifdef HAVE_GTECWD
#ifdef HAVE_GETCW
などと書いてしまったらどうなるか。このようなミスは、ヒューマンエラーなので、
頭の良さや経験や能力に関わらず、誰にでも起こりうる（なのに、エラーになら
ない。）。
また、それとは別に、例えば、その環境では
getcwd(pathname, sizeof(pathname));
の部分をコンパイラがパースすらしない場合、
getcwd(pathname. sizeof(pathname));
getcwd(pathname, sizeof(pathname)):
getcwd(pathname, sizoef(pathname)):
getcwd(pathname, sizeof(pathnmae));
などの書き間違いがあったらどうなるか。
, . ; : の間違いがあるが良く見ないと分からない。
これならまだコンパイル・エラーになるだけなので
まだ良くて、一度もテストしないなら、コンパイルは通るのに、
実行段階で結果だけがおかしくなることもありうる。その場合は
もっとたちが悪い。
頭の言いプログラマなら、別の方法を探す。
馬鹿だからその「解」が見つからない。
プリプロセッサに代わる頭の良いやり方を是非開発して
1つの方法としては、新規に共通(互換)ライブラリを作れば良い。
上の例だと最も単純には、
1. getcwd(pathname, sizeof(pathname));
2. getwd(pathname);
の「1」の方はアプリ・プログラムでは使わずに、必ず2を使うようにする。
そして2が存在しない環境向けには、
xxx getwd(zzz *pathname) // zzz は恐らく char
{
・・
aaa = getcwd(pathname, 最大パス文字数);
・・・
}
のような感じのライブラリ関数を提供してしまう。こうしてしまえば、
autotool なんてアプリをビルドする際には全く使わなくて良くなる。
長いパス名が使える環境向けには、「最大パス文字数」を動的に可変に
する方法も有り得る。そうするには工夫が必要だが不可能なことではない。
動作の切り分けはどうやってするのですか？
シンボル名の「衝突」と言っても色々な場合があり、一概には言えないが、
新しい共通ライブラリ関数は、例えば
cmn_getwd()
のように先頭に 「cmn_」を付けてしまって、アプリは、「cmn_xxx」の
方だけを使うようにすれば、衝突の心配が１つ消える。
名前変更した共通ライブラリをビルドするときはどう回避するの？
それは色々なやり方があるが、2つだけ書いておく:
1. そのライブラリのソースだけは、プラットフォームごとに場合分けしてしまう。
2. 何らかのツールで、関数ごとに使えるかどうかチェックし、1,0のフラグを
マクロに設定するヘッダフィルを作成し、そのマクロで#ifdefで場合分けする。
どちらの方法でも、ライブラリだけを誰かが集中的に徹底的にテストとバグ取りして、
ライブラリを作る人だけは、全プラットフォームでテストを徹底的にしさえすれば、
のような危険が生じる可能性を限りなく0に近づけられる。
本質的にプリプロセッサの問題を解決しておらず
欠陥品を頑張ってなんとかするというのは頭の良い解決策とは
余り言わないと思いますが。
だったら、プリプロセッサを改良すれば良いよ。
具体的に改良点も挙げずに言われても無意味ですし
プリプロセッサが改良できるならあなたが最初に上げた問題点も解決するのでは？
>プリプロセッサが改良できるならあなたが最初に上げた問題点も解決するのでは？
いや、それだけだと「」の前半の問題は解決するが、後半の問題は残る。
の方法を使えば、両方の問題を解決できる。モジュール別テストは強力だから。
>具体的に改良点も挙げずに言われても無意味ですし
の前半の問題を根本的に解決したければ、gccの前処理(プリプロセス)部分
に独自の前処理指令を追加すれば良い。
ただ、そこまでしなくても、の方法のようにすれば、モジュール別テストの効果で
非常に安定なプログラムを作り得る。
方法が具体的に何も提示されてないのですが。
一応、何度も「衝突回避」と書いてあるけど、「関数が定義されているか
どうかによる場合分け」みたいなことだよね。
その部分だけは、何らかのツールを使えばよい。最も単純な物でよければ、シェル
スクリプトでもいける。コンパイラ処理系によって違ってくるが、使うライブラリ
全てについて、ライブラリアンやリンカなどでexport symbolの一覧を出して、
関数名(シンボル名)が出力されるかを調べれば良い。それは、
librarian -list_exports xxx.lib | grep シンボル名
が1文字以上の何かを出力すれば真、何も出力しなければ偽、という
様な論理で良い。それをシェルスクリプトに書けば良い。
判定結果をどうやってソースコードに反映させるのですか？
あなたが今提案したようなことをautoconfがやっているということは
目をつむっておきますが。
Cでまともにプログラム書いた経験があるように見えないのですがね。
でそれはない。
言ってたけど、俺はMac使ってないからよく知らないけど、Ubuntuなら何でもパッケージ揃ってるじゃん・・ｗ
Macもネットとか見て大体想像つくけど、Ubuntuの方が上だろ・・？
Windowsの時の糞めんどくせえ環境変数の設定とか全然しなくていいからUbuntu大好き
ﾜﾛﾀよｗ Javaも最初のAutoexec.batにパス記載するのも、順番違うとコンパイルや実行できねえし・・ｗ
今のWindowsは良くしらんけども。
その昔umsdosってのがあってだな…実際ext2っぽいメタデータをVFAみたいに
VOLに詰め込む実装もあったんだよ。もうメンテされてないけど。
むしろ現代では逆にf2fsなんていうものでFATを模倣するような挙動を
androidでやってる。
昔は文字数制限がシビアでそれに引っかかった時に対処するのに四苦八苦してfindだとかいろいろ組み合わせただけだぞ
64bit OS用にしか precompiled 版がない。
どこが開発者に使いやすいものか。
500MB位DLを強要されそうになった。
もっとも、バイト数も表示されないので、推定だが。このバイト数も表示されない、というのも
LinuxのCLIパッケージ・マネージャーによくある問題点だ。Windowsだと、zipファイルのDL
サイズは速い段階で分かるが、Linuxだとスクリプトによっては最後まで分からないことが
ある。今回も「その分からないタイプの」スクリプトだった。
アメリカは高速回線でどうでも良いのかも知れんが、こっちはたまったもんじゃない。
apt-get や apt があるのかも分からない。
アホですか。
せっかくLinuxでやろうと思ったのに。
いつもこんな感じになっちまう。残念。。。
GoogleのChromeOSや、デスクトップ用のなんとかOSがなんとかしてくる
かも知れんが。
そうやって、色々な人が離れて行くんだろうよ、今までも、これからも。
というか、もはやボランティアの力だけではどうにもならん気もする、
DesktopでのLinuxは。やはりGoogleか。
自分たちの立ち位置が認識できてない。何一つマトモニなものが
ないというのに。
1．Winをリプレース出来るなどど考えるのはやめましょう。共用しましょう。
2. 印刷はあきらめましょう。
3. Wifiの使用はあきらめましょう。
4. 音楽・動画・画像の編集/制作はあきらめましょう。
5. Nvidia製品の使用は控えましょう。
6. 教本を買いましょう。Linux界に限ってはググレカスは遠回りです。
7. Ubuntuを我慢して使い続けましょう。
どっちも死んで環境刷新すりゃいいのに
初めて触ったエディタがvimになっちゃって。Macとかも東大が洗脳してる。
酷いもんだ。
Download Visual Studio Code - Mac, Linux, Windows
ttp://https://code.visualstudio.com/download 犬厨が棍棒持って恐竜追い回している間に
MSはロケット打ち上げて火星までいっちゃった感じ
