Linuxは、開発環境が40年前と同レベル (819ﾚｽ)
上下前次1-新
2(1): 1 [saga] 2018/03/10(土)12:15 ID:F9RE316x(2/3) AAS
>>1
01. (Makefile.amの作成) # 手作業
02. $ autoscan
03. [configure.scan生成] # 自動
04. $ cp configure.scan configure.ac
05. (configure.acの修正） # 手作業
06. $ aclocal
省8
3: 2018/03/10(土)12:21 ID:F9RE316x(3/3) AAS
馬鹿だから簡単に各方法を見出せず、ただただ、大量のツールを開発し、
時間をかけ苦労して使っている。そして大量の時間と膨大なHDD容量と、
ネット容量を使いまくって、それしかやる事が無い無能連中がOSS開発で
よってたかって、なんとか表面的には動くバグだらけの使えないツール類を
作りまくって出来上がった集大成が Linuxだ。
4(1): 2018/03/10(土)12:34 ID:GhVyQtCz(1) AAS
いまだにビルドが遅いんだよな
しかもカーネルをビルドできるだけでドヤ顔できるほどの難易度
コーディング中にリアルタイムでエラーが指摘される時代に何やってんだとは思う
5: 2018/03/10(土)12:38 ID:D1qSb8RL(1) AAS
ちゃんと動くんならいいじゃないか。
他のOSでは macOS High Sierra はちょい品質が…なのだし。
6: 2018/03/10(土)14:11 ID:eQWNUFiP(1) AAS
WindowsやiOSやmacOSのビルドは違うとでも思っているのだろうか…
7: 2018/03/10(土)14:31 ID:lzdUB3GL(1) AAS
LinuxだとVimとそれぞれの言語に応じたデバッガーだな
macOsだと糞Xcode
8: 2018/03/10(土)17:36 ID:zCz6mMg3(1) AAS
40年前の技術に後れをとる大企業マイクロソフトはどんだけ機能不全なんだよｗ
9: 2018/03/10(土)19:31 ID:kO7HFFeK(1) AAS
補助ツールのやってることが場当たりの対応でしかないから、
新しく作るものも場当たりの対応に合うように作ることになる切なさがある
そして今は逆に、みんな好き勝手にビルドツールを作る時代になって、それはそれで面倒くさいことに
10(1): 2018/03/10(土)21:14 ID:Iz6oQn3Q(1) AAS
>>1
> ファイルのコピーもdosなら、「copy *.c /xxx/aaa 」で済むことが
できないんだっけ？
11(1): 2018/03/10(土)23:08 ID:Trf+5FyR(1) AAS
DOSはコマンドラインの長さ制限が厳しすぎて*のファイル名展開したら
Linuxでcp *.c /xxx/aaaするより限界低そうだけどどうなんだろうな
12: 2018/03/11(日)01:56 ID:ceorHAxI(1) AAS
久しぶりに同意できる>>1
13(1): 2018/03/11(日)02:44 ID:W7wkl3nL(1) AAS
CUI で開発できるので、うれしい。
よく知らないGUIのOSだと、モヤモヤする。
14: 2018/03/11(日)07:43 ID:7srcRXE1(1/2) AAS
>>10
copyじゃなく、xcopyかな。
15: 2018/03/11(日)08:13 ID:7srcRXE1(2/2) AAS
>>11
DOSのcommand.comはワイルドカードを展開しない仕様だったからコマンドラインの
文字数制限の壁にかからなかった。一方、Linuxは、普段は cp *.c /xxx/aaa で行け
ても全てのファイル名の合計文字数が長くなればその制限に引っかかる。だから
結局、findを使わざるを得なくなることがある。そしてファイル数が多いときにもエラーを
絶対に起こさないためには最初からfindを使わざるを得ないと思う。じゃあなんのために、
bashのワイルドカード展開はあるかって話になるかも。
16: 2018/03/11(日)10:02 ID:FS0P3X2Y(1) AAS
>>13
知識がついてきてないだけやんｗｗｗｗ
17: 2018/03/11(日)11:16 ID:wZ7PAPAy(1) AAS
CUIはどこいっても似たようなもんだからな
GUIは文化の壁が厚すぎる
OS違ったら当然のこと、業界によっても常識が変わるからな
18: 2018/03/11(日)11:31 ID:1WQdp6Y+(1) AAS
ワイルドカードの展開は余計なお世話だと言いたいのかな。それなら抑止するオプションもあるのだが。
「この仕様はどんなメリットがあるの?」とか「DOS のこれは Linux ではどうやるの?」とかなら助けてやれるかもしれないのだが。
19(1): 2018/03/11(日)12:48 ID:YsLyPzcd(1) AAS
面倒でもあるが細かい所まで手を入れる事できるからまし。vsでビルドで謎エラーとか
20: 2018/03/12(月)03:16 ID:ZVV/4ff9(1) AAS
cmakeが主流になりつつあるだろ
誰も知らんのか
21(4): 2018/03/13(火)07:39 ID:bSKvTeow(1) AAS
autotoolsとCMake、正直どっちもつらみがある
CMakeなら.slnファイルも作れるという強みはあるが…
しかし>>1はいろいろと誤認や知識不足がみられるな
PATHに.入れればconfigureで実行できるようになるがセキュアでないので
推奨されない
今時のGUI環境ならPnPでディスクは勝手にマウントされる
wildcardの展開をshellまかせにするかコマンド側がよろしくやってくれるのかは
省2
22(1): 2018/03/13(火)10:22 ID:5bGA/MLX(1/6) AAS
>>21
>PATHに.入れればconfigureで実行できるようになるがセキュアでないので
>推奨されない
それでバランスしてしまったのがUnix文化の困ったところなんだ。
DOSだと、暗黙のうちに「.」が検索パスに入っていることが前提だからそれを
前提にした文化が形成されたので、その状態でも十分に「セキュア」になった。
その結果、./を付けなくてもカレント・ディレクトリのEXEやBATファイルを実行できる
省3
23(1): 2018/03/13(火)10:33 ID:5bGA/MLX(2/6) AAS
>>21
>今時のGUI環境ならPnPでディスクは勝手にマウントされる
Ubuntuだけど、
1. /etc/fstab に光学ドライブを書いておくと、Login前に待機状態になってしまう。
2. Login後、メディアを入れてからNautilusでドライブをクリックすると認識はできる。
3. しかし、メディアを交換したときにトラブルが生じやすい。例えば、Wineだ。
4. HDDですら、Nautilusでドライブをクリックせずに、いきなり端末を使った場合には
省5
24(1): 2018/03/13(火)10:35 ID:5bGA/MLX(3/6) AAS
>>21
>wildcardの展開をshellまかせにするかコマンド側がよろしくやってくれるのかは
>一長一短あるだろう
現実に良く使うコマンドがとても長くなってしまっているのだから、結果的にはLinuxの
方が使いにくい。
25: 2018/03/13(火)10:52 ID:5bGA/MLX(4/6) AAS
>>21
>Visual Studioがいい環境なのは認めるよ。
この書き方だと、プログラムの経験が浅い人にはVisual Studio だけが例外的に
「いい環境」なだけだと思われてしまう。
ところが、実際にはそうではなく、TurboC++, WatcomC++なども、十分に便利だった。
コマンドラインでも、gccやgnu make などとくらべて、だいぶ便利だったんだ。
はっきりいえば、gccやmakeやLinux文化は洗練されておらず、頭が悪いんだ。
26(1): 2018/03/13(火)11:51 ID:wIVMmkuq(1) AAS
Emacsだけ有ればいいさ！
27(1): 2018/03/13(火)12:29 ID:9i5woyma(1) AAS
makeは特別に良いとは言わないけど別に悪くもない
それより最近は言語に特化したビルドツールが多いから色々覚えなきゃいけないのが面倒
28: 2018/03/13(火)12:45 ID:5bGA/MLX(5/6) AAS
>>27
基本的には、make自身の問題よりも書き方やそれ以外の変なツールが標準になっていることの問題
が大きい。しかし、gnu toolsは、余計なメッセージだけを消す事が出来ないことが多いのが
クソなんだ。消そうと思うと全てのメッセージが消えたりして、使い物にならない。turbo c++
や watcom c++ , msc++, vc++のツール類は、どれもそんな初歩的な不具合は無かった。
29: 2018/03/13(火)12:55 ID:IE+orhWI(1) AAS
すごいな。いろんな意味で。現状に不満があるのは理解できたけど、不満を解消するために何をしたの?
30: 2018/03/13(火)13:08 ID:5bGA/MLX(6/6) AAS
それが責任者不在の問題点。こっちは部外者なのに責任を負わそうとする。
31: 2018/03/13(火)23:35 ID:WPjn7ohc(1) AAS
昔は、好きでやってる開発者に世界中のユーザーが支援して品質を高めていくオープンソースやフリーソフトに、
仕事で嫌々やってる商用ソフトがかなうわけないと思ってたけど、そうでもなかったな。
やっぱり仕事で真剣にやってる人たちにはかなわないんだな。
32: 2018/03/14(水)05:31 ID:4nEasH7v(1) AAS
jetbrainsのIDE使っとけば
33: 2018/03/14(水)07:17 ID:HRaHWJ8k(1/2) AAS
TURBO Cのコマンドラインは使ったことないな。IDEは便利だったけど。
ただ当時のレベルだったらemacsのmake+ctags環境も十分匹敵する
レベルだったと思うが。あの頃にリファクタリング機能とかなかっただろう。
jetbeansの名前も出てるけど、Eclipse, Anjuta, KDevelopみたいな
IDEもある中でそういうのを出して比較しないのはちょっとフェアじゃ
ないんじゃないか。
まあそれらと比較してもIntelliSenseに及ばないんだけど。
34(2): 2018/03/14(水)07:43 ID:HRaHWJ8k(2/2) AAS
>>22 出自が1マシンを複数ユーザーで使うことが前提の環境だったので
悪意あるユーザーの想定が必要だった。というかWindosが今の状態で
十分セキュアとは思えないんだけど。悪意あるユーザに勝手にファイル
置かれて実行されるリスクは下がっちゃいないのでは。
>>23 fstabを書いた例と書かない例を混ぜて文句いうのはちょっと感心しない。
FAT32はそもそもろくなメタデータおけなくてPOSIX的なファイルの扱い
にマッチしないのでそりゃしょうがないよとしかいえない。
省6
35: 2018/03/14(水)08:42 ID:4J3TJdzv(1/9) AAS
>>34
>全コピーしなくてもloopback filesystem置く手段はある。
こういうのを聞いて、イザやってみても別のところで不具合が起きて時間の無駄になった
経験が沢山ある。
36(1): 2018/03/14(水)09:11 ID:4J3TJdzv(2/9) AAS
>>34
>FAT32はそもそもろくなメタデータおけなくてPOSIX的なファイルの扱い
>にマッチしないのでそりゃしょうがないよとしかいえない。
数学的にはFAT32であってもext3の模倣もする事が出来る。
あなたは数学は苦手ですか？ 苦手なら、数学とプログラムと
UnixとWindowsとExt3とFAT32の全てに詳しい者に聞いてみるといい。
自分にはそれをするための方法が頭の中で分かる。そういうツールや
省2
37(1): 2018/03/14(水)16:11 ID:B9yzXWAU(1/2) AAS
なんでコンパイラと統合環境比べてるの？
統合環境でVSが良いのは認めるけどLinuxだってEclipseやJetbrainはあるし
38: 2018/03/14(水)16:13 ID:B9yzXWAU(2/2) AAS
WindowsってただVSが良いというだけじゃん
未だにまともなパッケージ管理もないしシェルは使えないし開発する環境としては最悪だよ
39: 2018/03/14(水)16:32 ID:q4XJOHSe(1) AAS
VisualStudioが便利な言語って限られるし
開発環境全般で言えばWindowsだけじゃ不足なのでWSLが持て囃されたりしてるし
万能なものはないからいいとこ取りで使っていればいいだけだ
40(1): 2018/03/14(水)16:48 ID:80z85C3j(1) AAS
MS-DOS を使っていた時代は、UNIX を使っている人たちが羨ましくて仕方なかったな。本当に何から何まで羨ましかった。
だから、Linux よりも DOS がいいというのはなかなか興味深い見解だと思ったのだが……どうやらお呼びじゃなさそうだ。
41: 2018/03/14(水)16:55 ID:4J3TJdzv(3/9) AAS
>>40
そりゃ、DOSはLinuxのサブセットみたいに普通思い勝ち。でも実際はむしろMSが
進化させたんじゃないかと、今では思ってる。実際MS製Unixは売れずにDOS
だけが売れたし。
42: 2018/03/14(水)17:03 ID:4J3TJdzv(4/9) AAS
>>37
コマンドライン・コンパイラを比較してもやはり、TurboC++, WatcomC++などとくらべて
gnu tools は使いにくいと思ってるし、上でもそう書いてる。
43(1): 2018/03/14(水)17:22 ID:Ot1p/P4U(1/2) AAS
使いこなせないだけだろｗ
44(1): 2018/03/14(水)17:22 ID:KnbtLvIZ(1) AAS
autotoolsはマルチプラットフォームを前提としたものだからTurboとかとは目的が違う
別のOSでも同様の手順でいいという使い勝手はTurboCとかじゃ実現できないわけで結局使い易いとかは主観でしかないしどれだけ自分に都合が良いかというだけのこと
45: 2018/03/14(水)17:26 ID:4J3TJdzv(5/9) AAS
>>43
色々な嘘によって、ミュンヘン市は損害を追ったのに、Linuxサイドは「技術的な問題じゃない」
という一点張り。スラドではこの態度に対し、「なんと言う言い訳」と言われてた。
46(1): 2018/03/14(水)17:26 ID:Ot1p/P4U(2/2) AAS
使いやすいとか使いにくいは慣れの問題だし
最初に手をそめた環境がその人の一生の好みを決めるところがある
自分の好みを言っても主観以外のなにものでもない
47: 2018/03/14(水)17:30 ID:4J3TJdzv(6/9) AAS
>>46
LibreOfficeの開発者もそんな事言ってた・・・。
48: 2018/03/14(水)17:58 ID:4J3TJdzv(7/9) AAS
欧米流は、言い訳が多いな。
49: 2018/03/14(水)18:31 ID:4J3TJdzv(8/9) AAS
>>44
ただ、そんなことしなくても(30年前に比べれば)言語やOSで色々と統一化や
標準化もあったりしたせいか、それらのツールのやり方が本末転倒で意味不明
な存在になってり。
今は、そもそも出来ない場合にはそんなツール使っても出来ないし、出来る
場合には使わなくても出来る。存在意義がどれくらい果たしてあるのか。
50(1): 2018/03/14(水)18:51 ID:rvms1pqi(1/2) AAS
出来るかどうかってのは使う人間の能力によるところが大きいから出来なかったとしても仕方がない
51: 2018/03/14(水)18:57 ID:4J3TJdzv(9/9) AAS
>>50
今は、「マルチプラットフォーム」での非互換部分を自動的に修正してくれるかどうかの話
やで。
52: 2018/03/14(水)19:32 ID:rvms1pqi(2/2) AAS
そのソフトウェアがそのOSに対応してるのなら自動的に追従するようになってるだろ
想定されたOSでそれが出来ないということなら問題は人間側に(以下略
53(1): 2018/03/14(水)23:56 ID:qC2L6BuB(1) AAS
スレタイだけでの反応なんだけれど、
16年前に書いたソース群を、今日makeする事ができた。
これ、本当に凄い事だと思う。1回覚えた事や環境がずっと使えるって幸せ。
54: 2018/03/15(木)00:25 ID:cRQ+JQN/(1) AAS
>>1 読むと、autoconfは確かに面倒なの同意。
良書がなかったしね。訳本も酷かった。本当に酷かった。
そもそもポータビリティに気を付けてソースを書きなさい。
後は、色んな環境でもmakeできるようにしてあげるよって思想だった記憶。
お陰でvine2.1.5時代に作った物が今でもmakeできた。
ただ、思い出して修正できるまでに10日かかった。
当時も日本人開発のソフトには導入が不完全で、バグレポート送ったりしてたわ。
55: 2018/03/15(木)10:44 ID:lnWZyj3L(1/14) AAS
えっ!?
外部ﾘﾝｸ[html]:www.jaist.ac.jp
>autoconf/automakeのバージョンを少し上げただけで、 それまでに作成した
>configure.inに対してautoconf/automakeを実行すると エラーや警告を生じる
>ようになる場合が多々あります。 むやみに最新バージョンをインストールし
>ないほうがよいようです。
>以降の記述でも、autoconf/automakeのバージョンによってはエラーや警告
省1
56(1): 2018/03/15(木)10:52 ID:lnWZyj3L(2/14) AAS
どっちの関数があるかないかによって、自分のコードにこんなの書かされる。
片方の環境しかなければ、もう片方のテストはしないってことだよね。
#ifdef HAVE_GETCWD
getcwd(pathname, sizeof(pathname));
#else
# ifdef HAVE_GETWD
getwd(pathname);
省4
57(3): 2018/03/15(木)11:03 ID:lnWZyj3L(3/14) AAS
例えば、マクロ名を間違って、
#ifdef HAVE_GETCVD
#ifdef _HAVE_GETCWD
#ifdef HAVE_GET_CWD
#ifdef HAVE_GTECWD
#ifdef HAVE_GETCW
などと書いてしまったらどうなるか。このようなミスは、ヒューマンエラーなので、
省15
58(1): 2018/03/15(木)14:29 ID:LTp8xgxY(1/9) AAS
それはCプリプロセッサの問題だろ
59(1): 2018/03/15(木)14:49 ID:lnWZyj3L(4/14) AAS
>>58
頭の言いプログラマなら、別の方法を探す。
馬鹿だからその「解」が見つからない。
60(1): 2018/03/15(木)14:57 ID:LTp8xgxY(2/9) AAS
>>59
プリプロセッサに代わる頭の良いやり方を是非開発して
61: 2018/03/15(木)15:07 ID:lnWZyj3L(5/14) AAS
>>60
1つの方法としては、新規に共通(互換)ライブラリを作れば良い。
上の例だと最も単純には、
1. getcwd(pathname, sizeof(pathname));
2. getwd(pathname);
の「1」の方はアプリ・プログラムでは使わずに、必ず2を使うようにする。
そして2が存在しない環境向けには、
省10
62(1): 2018/03/15(木)15:18 ID:LTp8xgxY(3/9) AAS
そのやり方は無造作にやるとシンボル名が衝突してコンパイルやリンクエラーになりますが
動作の切り分けはどうやってするのですか？
63(1): 2018/03/15(木)15:25 ID:lnWZyj3L(6/14) AAS
>>62
シンボル名の「衝突」と言っても色々な場合があり、一概には言えないが、
新しい共通ライブラリ関数は、例えば
cmn_getwd()
のように先頭に 「cmn_」を付けてしまって、アプリは、「cmn_xxx」の
方だけを使うようにすれば、衝突の心配が１つ消える。
64(1): 2018/03/15(木)15:36 ID:LTp8xgxY(4/9) AAS
>>63
名前変更した共通ライブラリをビルドするときはどう回避するの？
65(3): 2018/03/15(木)16:15 ID:lnWZyj3L(7/14) AAS
>>64
それは色々なやり方があるが、2つだけ書いておく:
1. そのライブラリのソースだけは、プラットフォームごとに場合分けしてしまう。
2. 何らかのツールで、関数ごとに使えるかどうかチェックし、1,0のフラグを
マクロに設定するヘッダフィルを作成し、そのマクロで#ifdefで場合分けする。
どちらの方法でも、ライブラリだけを誰かが集中的に徹底的にテストとバグ取りして、
ライブラリを作る人だけは、全プラットフォームでテストを徹底的にしさえすれば、
省1
66(1): 2018/03/15(木)16:34 ID:LTp8xgxY(5/9) AAS
>>65
本質的にプリプロセッサの問題を解決しておらず
欠陥品を頑張ってなんとかするというのは頭の良い解決策とは
余り言わないと思いますが。
67(1): 2018/03/15(木)16:37 ID:lnWZyj3L(8/14) AAS
>>66
だったら、プリプロセッサを改良すれば良いよ。
68(2): 2018/03/15(木)16:53 ID:LTp8xgxY(6/9) AAS
>>67
具体的に改良点も挙げずに言われても無意味ですし
プリプロセッサが改良できるならあなたが最初に上げた問題点も解決するのでは？
69: 2018/03/15(木)17:00 ID:lnWZyj3L(9/14) AAS
>>68
>プリプロセッサが改良できるならあなたが最初に上げた問題点も解決するのでは？
いや、それだけだと「>>57」の前半の問題は解決するが、後半の問題は残る。
>>65の方法を使えば、両方の問題を解決できる。モジュール別テストは強力だから。
70: 2018/03/15(木)17:04 ID:lnWZyj3L(10/14) AAS
>>68
>具体的に改良点も挙げずに言われても無意味ですし
>>57の前半の問題を根本的に解決したければ、gccの前処理(プリプロセス)部分
に独自の前処理指令を追加すれば良い。
ただ、そこまでしなくても、>>65の方法のようにすれば、モジュール別テストの効果で
非常に安定なプログラムを作り得る。
71(1): 2018/03/15(木)17:11 ID:LTp8xgxY(7/9) AAS
共通ライブラリのビルド時にシンボル名の衝突回避をプラットフォーム毎に判別する
方法が具体的に何も提示されてないのですが。
72(1): 2018/03/15(木)17:20 ID:lnWZyj3L(11/14) AAS
>>71
一応、何度も「衝突回避」と書いてあるけど、「関数が定義されているか
どうかによる場合分け」みたいなことだよね。
その部分だけは、何らかのツールを使えばよい。最も単純な物でよければ、シェル
スクリプトでもいける。コンパイラ処理系によって違ってくるが、使うライブラリ
全てについて、ライブラリアンやリンカなどでexport symbolの一覧を出して、
関数名(シンボル名)が出力されるかを調べれば良い。それは、
省3
73: 2018/03/15(木)17:23 ID:lnWZyj3L(12/14) AAS
スマンが、用事があるのでしばらく抜ける。
74(1): 2018/03/15(木)17:34 ID:LTp8xgxY(8/9) AAS
>>72
判定結果をどうやってソースコードに反映させるのですか？
あなたが今提案したようなことをautoconfがやっているということは
目をつむっておきますが。
75: 2018/03/15(木)17:36 ID:LTp8xgxY(9/9) AAS
というか既存のビルドシステムや共通ライブラリの実装に精通してないどころか
Cでまともにプログラム書いた経験があるように見えないのですがね。
76: 2018/03/15(木)17:37 ID:lnWZyj3L(13/14) AAS
いや、実際に上司などからも、滅多にいない最高レベルのプログラマだと評されていたの
でそれはない。
77: 2018/03/15(木)17:38 ID:lnWZyj3L(14/14) AAS
さらにいえば、昔から神童だと言われてきた。
78: 2018/03/15(木)20:09 ID:ewca0ZvD(1/2) AAS
っていうか、ビル・ゲイツが今時のできるプログラマは間違いなくMacを使ってるとか
言ってたけど、俺はMac使ってないからよく知らないけど、Ubuntuなら何でもパッケージ揃ってるじゃん・・ｗ
Macもネットとか見て大体想像つくけど、Ubuntuの方が上だろ・・？
Windowsの時の糞めんどくせえ環境変数の設定とか全然しなくていいからUbuntu大好き
79: 2018/03/15(木)20:12 ID:ewca0ZvD(2/2) AAS
Windows９８の頃なんて、VC買ってやってみたけど、インテリセンスの出てくるのが糞遅くて
ﾜﾛﾀよｗ Javaも最初のAutoexec.batにパス記載するのも、順番違うとコンパイルや実行できねえし・・ｗ
今のWindowsは良くしらんけども。
80: 2018/03/15(木)20:49 ID:9s2u5/Ot(1) AAS
ゲイツそんなこと言ったの？
81: 2018/03/15(木)21:50 ID:7HZLjuXm(1) AAS
>>36
その昔umsdosってのがあってだな…実際ext2っぽいメタデータをVFAみたいに
VOLに詰め込む実装もあったんだよ。もうメンテされてないけど。
むしろ現代では逆にf2fsなんていうものでFATを模倣するような挙動を
androidでやってる。
82: 2018/03/23(金)00:19 ID:uVffKzsn(1) AAS
1がアホなのはわかったｗ
昔は文字数制限がシビアでそれに引っかかった時に対処するのに四苦八苦してfindだとかいろいろ組み合わせただけだぞ
上下前次1-新書関写板覧索設栞歴
あと 737 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.030s