Linuxは、開発環境が40年前と同レベル (819ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
1(12): 2018/03/10(土)12:14 ID:F9RE316x(1/3)調 AAS
間違ってもらっては困るのは、それはコマンドライン・メインなのが主因ではないということ。
本当の一因は、本来手書きでも簡単な 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信奉者の愚かさもアホとしか言いようがない。
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
07. $ automake -a
08. [Makefile.in生成] # 自動
09. $ autoheader
10. [config.h.in生成] # 自動
11. $ autoconf
12. [configure生成] # 自動
13. $ ./configure実行
14. [Makefile生成] # 自動
10(1): 2018/03/10(土)21:14 ID:Iz6oQn3Q(1)調 AAS
>>1
> ファイルのコピーもdosなら、「copy *.c /xxx/aaa 」で済むことが
できないんだっけ？
12: 2018/03/11(日)01:56 ID:ceorHAxI(1)調 AAS
久しぶりに同意できる>>1
21(4): 2018/03/13(火)07:39 ID:bSKvTeow(1)調 AAS
autotoolsとCMake、正直どっちもつらみがある
CMakeなら.slnファイルも作れるという強みはあるが…
しかし>>1はいろいろと誤認や知識不足がみられるな
PATHに.入れればconfigureで実行できるようになるがセキュアでないので
推奨されない
今時のGUI環境ならPnPでディスクは勝手にマウントされる
wildcardの展開をshellまかせにするかコマンド側がよろしくやってくれるのかは
一長一短あるだろう
Visual Studioがいい環境なのは認めるよ。VSCodeはその域に達してないし
54: 2018/03/15(木)00:25 ID:cRQ+JQN/(1)調 AAS
>>1 読むと、autoconfは確かに面倒なの同意。
良書がなかったしね。訳本も酷かった。本当に酷かった。
そもそもポータビリティに気を付けてソースを書きなさい。
後は、色んな環境でもmakeできるようにしてあげるよって思想だった記憶。
お陰でvine2.1.5時代に作った物が今でもmakeできた。
ただ、思い出して修正できるまでに10日かかった。
当時も日本人開発のソフトには導入が不完全で、バグレポート送ったりしてたわ。
222(1): 2018/09/09(日)12:21 ID:gnEdZr1c(1/59)調 AAS
>>221
テキストエディタでXMLの設定ファイルを編集しても面倒なだけだから
かといってXMLの設定ファイルを持ってるアプリが設定ツールが
あるかといえば無いだろう？設定ツールも作るのは大変だからね
キーとバリューの使い方を間違えたんだよ。
たいていXML設定ファイルはこんな感じになってる
https://help.adobe.com/ja_JP/air/build/WSEC63CD64-C52C-41ef-82FD-94E6B540A5FA.html
<configuration xmlns="http://ns.adobe.com/air/framework/update/configuration/1.0">
<url>http://example.com/updates/update.xml</url>
<delay>1</delay>
<defaultUI>
<dialog name="checkForUpdate" visible="false" />
<dialog name="downloadUpdate" visible="false" />
<dialog name="downloadProgress" visible="false" />
</defaultUI>
</configuration>
こんなの独自のタグばっかりあるんじゃ汎用のツールで扱えるわけがない
487(2): 2018/09/19(水)03:03 ID:1IXftWFL(1)調 AAS
> もちろん開発初期は、<input>並べただけだからろくな見た目ではないが
> それでも使える。後々作り込めばいいし、プログラマじゃない人でも手伝うことができる。
enum Items {item1,item2,item3};
class Configurations {
int foo;
Items bar;
bool baz;
}
Configurations configurations;
なら
<configurations type="Configurations">
<foo type="int">1</foo>
<bar type="Items">item1</bar>
<baz type="bool">true</baz>
</configurations>
なら助かるけど
<configurations>
<foo>1</foo>
<bar>item1</bar>
<baz>true</baz>
</configurations>
でもまったく問題ないな
もちろん初期は、全てtype="string"として扱うだけだが
それでも使える。後々type="bool"なりtype="Items"なりスキーマなどで定義すりゃいいし、プログラマじゃない人でも手伝うことができる
アプリ作者は何もしなくていい
設定ツールの作者にとっても
bool,int,Itemsなどをどう扱うかは設定ツールの作者が好きにしたらいい
もちろん開発初期は、すべて<input>並べただけだからろくな見た目ではないが
それでも使える。後々Itemsをセレクトボックスで選べるようにしたりboolをcheckboxなり好き勝手に作り込めばいい
572(2): 2018/09/27(木)10:48 ID:edwYQ+4S(1)調 AAS
>>567
アプリの作者からすると<foo>1</foo>で事足りる
設定ツールの作者からしても
input + number という無駄情報より
type="int" という型情報
のほうが正確というかそのものなのでありがたいな
697(2): 2018/11/14(水)15:34 ID:R9HUvO/L(1/3)調 AAS
>>1
Unix は世界最古のOSらしいので、最初は良かれと思って決めたものが、
使ってみると使いにくかった、ということはあるかもしれない。
一例として、
$ コマンド名 パラメータ >a
などとして、リダイレクトするとき、stdout と stderr が分かれている
のも、現実的には不便。
$ . スクリプト名
と先頭にピリオドをつけないと環境変数がスクリプトによって設定できない
のも不便。
どちらも、DOS では修正されていた。DOS の方が後発だから。
703(1): 2018/11/15(木)11:06 ID:xZi0sQ1j(2/7)調 AAS
>>1
なんという愚かなOSなんだろう。
DOSと同じことがこんなに長くなる :
[DOS]
$ コマンド名 >a
[Linux]
$ コマンド名 1>a 2>&1
731: 2018/11/18(日)01:55 ID:Vr4U8zB+(1/2)調 AAS
>>1
gcc や clang も、include path の設定が無視されることがある。
複雑に複数の言語処理系がインストールされている場合に、
include path が勝手に「コマンドPATHから推定して」 決められて
しまい、それを修正したいために、環境変数などを設定しても
優先順位がおかしくて、なかなか修正されないことがある。
しかも、その状況を確認するには、-v オプションを付けて
出てくる長いメッセージを解読しなくてはならない。
また実は、バイナリになってしまってからは修正すること
が難しいパス設定が存在することもある。
その場合は、ソースから make する際に、./configure
のパラメータで決められてしまっている。
つまり、バイナリレベルでは、動作が変えられるように
出来ていない欠陥品が多い。
761: 2021/08/20(金)16:43 ID:CQ/ekRlE(1)調 AAS
>>1
こいつの頭のみが40年前というのが結論
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.039s