diary/Kojima/2013-09-13
の編集
http://plamo.linet.gr.jp/?diary/Kojima/2013-09-13
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
|
ログイン
]
-- 雛形とするページ --
diary/Template
[[diary/Kojima]] ・Unix/Linuxの魅力(魔力) Unix/Linux環境の魅力(魔力)はいろいろあるけれど, 個人的に一番便利だと思っているのは、 同じような作業をシェルスクリプトを使ってごく簡単に自動化できることだと思っている。 例えば、今、KDE-4.11.1のパッケージをビルドしているのだけれど、 Plamo-5.1用に作ったKDE-4.9.5用のビルドスクリプトは揃っているので、 それらを微調整して4.11.1用にしたい。 Plamoのビルドスクリプトの場合、 バージョン番号等の情報はビルドスクリプトの先頭部分に集めているので、 ビルド処理を変える必要が無い場合、 そこの数字を書き変えるだけで新しいバージョンにも対応できる。 例えば、kdetoys-4.9.5のビルドスクリプトの先頭部分は、 #!/bin/sh ############################################################## url='ftp://ftp.kddlabs.co.jp/X/kde/stable/4.9.5/src/kdetoys-4.9.5.tar.xz' pkgbase=kdetoys vers=4.9.5 arch=x86_64 # arch=i586 build=P1 src=kdetoys-4.9.5 OPT_CONFIG='' DOCS='AUTHORS COPYING COPYING.DOC COPYING.LIB README' patchfiles='' compress=txz ############################################################## こういう風になっているけど、これらの"4.9.5"を"4.11.1"にすれば、 kdetoys-4.11.1もビルドできるはず。 最初は、/usr/share/doc/ 以下にあるビルドスクリプトを作業領域にコピーして、 それぞれのバージョン番号を手作業で修正していたけど、 同じ作業の繰り返しに飽き飽きしてきたので、シェルスクリプトにしてみた。 #!/bin/sh ov=4.9.5 nv=4.11.1 txz=$1 pkg=${txz%%.tar.xz} base=${pkg%%-${nv}} o_bs="PlamoBuild."$base"-"$ov n_bs="PlamoBuild."$base"-"$nv build_script="/usr/share/doc/"$base"-"$ov"/"$o_bs".gz" echo $txz, $pkg, $base, $o_bs, $build_script if [ -f $build_script ]; then cp $build_script ./$n_bs".gz" gunzip $n_bs".gz" sed -i -e "s/$ov/$nv/g" $n_bs fi こんなスクリプトを kde_conv.sh みたいな名前で保存しておいて、 $ ./kde_conv.sh kdetoys-4.11.1.tar.xz としてやると、/usr/share/doc/PlamoBuild.kdetoys-4.9.5.gz を PlamoBuild.kdetoys-4.11.1.gzとしてコピーして展開し、 内部の"4.9.5"というバージョン番号を"4.11.1"に書き変えてしまう、 という仕組み。 こうすれば、古いビルドスクリプトをコピーして、手作業で修正して、、 という手順がスクリプト一つ実行するだけで済むので、 同じ作業を延々と繰り返すパッケージ作り作業がずいぶん楽になる。 GUI環境だと、同じ作業が100回必要だと100回同じ作業をしなければいけないものの、 CUI環境だと、同じ作業を10回もやると飽きてきて、 本来の作業よりもこういうチート技の開発に走るのだけど往々にしてチート技に凝りすぎて、 同じ作業を100回やるよりも余計に時間がかかったりすることもあったりするのは御愛嬌(苦笑 - このあたり、GUI vs CUI というわけではなく、ソフトウェアに対する考え方(一つのツールで完結するか、開放系にするか)のレベルの違いだと思ふ。今の世の中、「何でもできる便利なツール」として多機能を詰め込んだ閉鎖系のソフトウェアが評価されがちだけど、応用可能性という点では開放系の「ソフトウェア・ツールズ」という考え方の方が優れている、というのは後世に伝えないといけないと感じるところ。 -- [[kojima]] &new{2013-09-13 (金) 20:33:54}; - ごもっともです。 -- [[Plamo大好]] &new{2013-09-18 (水) 19:21:44};
タイムスタンプを変更しない
[[diary/Kojima]] ・Unix/Linuxの魅力(魔力) Unix/Linux環境の魅力(魔力)はいろいろあるけれど, 個人的に一番便利だと思っているのは、 同じような作業をシェルスクリプトを使ってごく簡単に自動化できることだと思っている。 例えば、今、KDE-4.11.1のパッケージをビルドしているのだけれど、 Plamo-5.1用に作ったKDE-4.9.5用のビルドスクリプトは揃っているので、 それらを微調整して4.11.1用にしたい。 Plamoのビルドスクリプトの場合、 バージョン番号等の情報はビルドスクリプトの先頭部分に集めているので、 ビルド処理を変える必要が無い場合、 そこの数字を書き変えるだけで新しいバージョンにも対応できる。 例えば、kdetoys-4.9.5のビルドスクリプトの先頭部分は、 #!/bin/sh ############################################################## url='ftp://ftp.kddlabs.co.jp/X/kde/stable/4.9.5/src/kdetoys-4.9.5.tar.xz' pkgbase=kdetoys vers=4.9.5 arch=x86_64 # arch=i586 build=P1 src=kdetoys-4.9.5 OPT_CONFIG='' DOCS='AUTHORS COPYING COPYING.DOC COPYING.LIB README' patchfiles='' compress=txz ############################################################## こういう風になっているけど、これらの"4.9.5"を"4.11.1"にすれば、 kdetoys-4.11.1もビルドできるはず。 最初は、/usr/share/doc/ 以下にあるビルドスクリプトを作業領域にコピーして、 それぞれのバージョン番号を手作業で修正していたけど、 同じ作業の繰り返しに飽き飽きしてきたので、シェルスクリプトにしてみた。 #!/bin/sh ov=4.9.5 nv=4.11.1 txz=$1 pkg=${txz%%.tar.xz} base=${pkg%%-${nv}} o_bs="PlamoBuild."$base"-"$ov n_bs="PlamoBuild."$base"-"$nv build_script="/usr/share/doc/"$base"-"$ov"/"$o_bs".gz" echo $txz, $pkg, $base, $o_bs, $build_script if [ -f $build_script ]; then cp $build_script ./$n_bs".gz" gunzip $n_bs".gz" sed -i -e "s/$ov/$nv/g" $n_bs fi こんなスクリプトを kde_conv.sh みたいな名前で保存しておいて、 $ ./kde_conv.sh kdetoys-4.11.1.tar.xz としてやると、/usr/share/doc/PlamoBuild.kdetoys-4.9.5.gz を PlamoBuild.kdetoys-4.11.1.gzとしてコピーして展開し、 内部の"4.9.5"というバージョン番号を"4.11.1"に書き変えてしまう、 という仕組み。 こうすれば、古いビルドスクリプトをコピーして、手作業で修正して、、 という手順がスクリプト一つ実行するだけで済むので、 同じ作業を延々と繰り返すパッケージ作り作業がずいぶん楽になる。 GUI環境だと、同じ作業が100回必要だと100回同じ作業をしなければいけないものの、 CUI環境だと、同じ作業を10回もやると飽きてきて、 本来の作業よりもこういうチート技の開発に走るのだけど往々にしてチート技に凝りすぎて、 同じ作業を100回やるよりも余計に時間がかかったりすることもあったりするのは御愛嬌(苦笑 - このあたり、GUI vs CUI というわけではなく、ソフトウェアに対する考え方(一つのツールで完結するか、開放系にするか)のレベルの違いだと思ふ。今の世の中、「何でもできる便利なツール」として多機能を詰め込んだ閉鎖系のソフトウェアが評価されがちだけど、応用可能性という点では開放系の「ソフトウェア・ツールズ」という考え方の方が優れている、というのは後世に伝えないといけないと感じるところ。 -- [[kojima]] &new{2013-09-13 (金) 20:33:54}; - ごもっともです。 -- [[Plamo大好]] &new{2013-09-18 (水) 19:21:44};
テキスト整形のルールを表示する