Linuxは、開発環境が40年前と同レベル (819ﾚｽ)
上下前次1-新
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のバージョンによってはエラーや警告
>が発生する場合があります。
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);
# endif
#endif
このようなコードを何回も書くのは駄目コードだ。なぜなら、1文字でも間違って
いればバグるのに、テストも出来ないから。
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
などと書いてしまったらどうなるか。このようなミスは、ヒューマンエラーなので、
頭の良さや経験や能力に関わらず、誰にでも起こりうる（なのに、エラーになら
ない。）。
また、それとは別に、例えば、その環境では
getcwd(pathname, sizeof(pathname));
の部分をコンパイラがパースすらしない場合、
getcwd(pathname. sizeof(pathname));
getcwd(pathname, sizeof(pathname)):
getcwd(pathname, sizoef(pathname)):
getcwd(pathname, sizeof(pathnmae));
などの書き間違いがあったらどうなるか。
, . ; : の間違いがあるが良く見ないと分からない。
これならまだコンパイル・エラーになるだけなので
まだ良くて、一度もテストしないなら、コンパイルは通るのに、
実行段階で結果だけがおかしくなることもありうる。その場合は
もっとたちが悪い。
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が存在しない環境向けには、
xxx getwd(zzz *pathname) // zzz は恐らく char
{
・・
aaa = getcwd(pathname, 最大パス文字数);
・・・
}
のような感じのライブラリ関数を提供してしまう。こうしてしまえば、
autotool なんてアプリをビルドする際には全く使わなくて良くなる。
長いパス名が使える環境向けには、「最大パス文字数」を動的に可変に
する方法も有り得る。そうするには工夫が必要だが不可能なことではない。
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で場合分けする。
どちらの方法でも、ライブラリだけを誰かが集中的に徹底的にテストとバグ取りして、
ライブラリを作る人だけは、全プラットフォームでテストを徹底的にしさえすれば、
>>56-57 のような危険が生じる可能性を限りなく0に近づけられる。
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の一覧を出して、
関数名(シンボル名)が出力されるかを調べれば良い。それは、
librarian -list_exports xxx.lib | grep シンボル名
が1文字以上の何かを出力すれば真、何も出力しなければ偽、という
様な論理で良い。それをシェルスクリプトに書けば良い。
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でまともにプログラム書いた経験があるように見えないのですがね。
上下前次1-新書関写板覧索設栞歴
あと 744 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.019s