[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-devel:18210] Re: [Q] debhelper v9対応にすべき?
野島です。どもども。
> あと、kanatestがさっくりDEB_BUILD_OPTIONS='noopt'の影響を受けないの
は、
> > upstream付属のconfigure.ac内部でCFLAGSを全面的に上書きしているから
だった
> > りします。debian/patch/* にこのあたりの修正含めてdh_autoreconfigとか
検討
> > しまする。
>
> configure.ac 内ではそのようなことをしているように見えません。
> 野島さんの見解は現在の configure では debian/rules で CFLAGS を指定し
ても、
> make 実行時は反映されないということでしょうか。
>
大変申し訳ないです。上の指摘を受けてもろもろ確認して自分の記載を全面的に書き直します。
(1) configureの段階で、CFLAGSは決め打ちに見えます。
------kanatest-0.4.8のconfigure.ac該当部分-----
CFLAGS="$BUILD_CFLAGS -Wall $PLATFORM_CFLAGS -D_GNU_SOURCE"
CXXFLAGS="$CFLAGS"
CPPFLAGS="$gtk_CFLAGS $xml_CFLAGS"
LIBS="$gtk_LIBS $xml_LIBS"
------kanatest-0.4.8のconfigure.ac該当部分-----
みての通り、configure外でCFLAGSにあらかじめ何かを設定してもconfigure内部で値が上書き代入される
形となってます。もちろん、BUILD_CFLAGSとか、PLATFORM_CFLAGSとかを別途debian/rulesで
いじるように改造すればCFLAGSに反映できるとは思いますが、現行のdebian/rulesでは、
そうなっておらず、また、BUILD_CFLAGS/PLATFORM_CFLAGSをデフォルトで直接設定するdebian関係のツール
もないと思ってます。もちろん、BUILD_CFLAGS:=$(shell dpkg-buildflags --get CFLAGS)とか
debian/rulesに搭載すればいいという話もありますが、CFLAGSをconfigure内部に取り込むにはCFLAGSを使う
というのが慣習かと自分は思っており、dpkg-buildflagsもCFLAGS経由でコンパイルオプションを引き渡す事を
意図してるように見えるので、configure外部で指定したCFLAGSをconfigure内部に引き継ぐ形にした方が将来に渡って
都合が良いかなと思いました。
(2) debian/rulesで
----- kanatest 0.4.8のdebian/rules抜粋 --------
build: build-stamp
build-stamp: config.status
dh_testdir
$(MAKE) CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs -Wl,--as-needed"
touch build-stamp
------kanatest 0.4.8のdebian/rules抜粋
とあるので、CFLAGSをdebian/rulesで変更すれば確かにmakeの時点でCFLAGSは反映されます。が、
せっかくconfigureでいろいろテスト／オプションを加味して得たはずのCFLAGSを
さっくりまるごと無視して上書する形なので、そもそもupstreamの意図にそった指定方法なのかが心配です。
※まあ、upstreamがそれでOKって言えば問題ないです。ここはまだ未確認。
(1),(2)を検討して、自分的に考えた結果、現行のkanatestのdebian/rulesを尊重した上で簡易的な変更を積み重ねるぐらいなら、
configure.acにて外部指定のCFLAGSを引き継ぐ形にし、
（configure.acにて、CFLAGS="$CFLAGS $BUILD_CFLAGS -Wall $PLATFORM_CFLAGS -D_GNU_SOURCE"とかに改造）
にしてautoreconfをやれば、将来v5廃止されてv9対応の書き方にdebian/rulesを変更されてもそのままで対応可能に見えるし、
（dhはcompatに9指定で、デフォルトで内部的にdpkg-buildflagsを実行してCFLAGSを自動的に設定してconfigureする機能がある）
configureの実行された結果としてのCFLAGSが設定されるので、動作の方向としても正しい気がする
と思いました。
---
Takahide Nojima <nozzy123nozzy@xxxxxxxxx>
2012-03-01 (木) の 09:16 +0900 に Nobuhiro Iwamatsu さんは書きました:
> こんにちは。岩松です。
>
> 2012年2月29日10:57 Takahide Nojima <nozzy123nozzy@xxxxxxxxx>:
> > 野島です。
> >
> >>正しくないと思います。
> >> debhelper はパッケージ作成/サポートツールの一つです。新しい debhelper
> > がリリースされたから
> >> といって追従する必要はありません。
> >
> > 了解しました。
> >
> >>DEB_BUILD_OPTIONS の処理を追加すればよいだけで、debhelper は関係ないで
> > す。
> >>
> >
> > はい。全くもってそのとおりでして。ただ、v9からdhが内部でdpkg-buildflags
> > 相当を呼び出してDEB_BUILD_OPTIONS見ながら適当にCFLAGSとか設定してくれる
> > ので、
> > debian/rulesが
> > #!/usr/bin/make -f
> > %:
> > dh $@ --with quilt
> >
> > とかだけになって、シンプルでいいなぁとおモタ次第です。はい。
> >
> > あと、kanatestがさっくりDEB_BUILD_OPTIONS='noopt'の影響を受けないのは、
> > upstream付属のconfigure.ac内部でCFLAGSを全面的に上書きしているからだった
> > りします。debian/patch/* にこのあたりの修正含めてdh_autoreconfigとか検討
> > しまする。
>
> configure.ac 内ではそのようなことをしているように見えません。
> 野島さんの見解は現在の configure では debian/rules で CFLAGS を指定しても、
> make 実行時は反映されないということでしょうか。
> >
> > ただ、パッケージ開発側でautotools関係のファイルに無邪気にパッチあてて
> > autoreconfしてよいかどうかは、議論の余地がある事が前回の東京エリアDebian
> > 勉強会で指摘されていたりします。
>
> 岩松
>