[Build-common-hackers] Using CDBS' flavors mechanism to build packages
dr at jones.dk
Sun Dec 19 03:15:35 UTC 2010
On Sun, Dec 19, 2010 at 01:47:48AM +0000, Emilio Pozuelo Monfort wrote:
>On 11/12/10 15:30, Jonas Smedegaard wrote:
>>On Sat, Dec 11, 2010 at 02:09:58PM +0000, Emilio Pozuelo Monfort
>>>I want to start using the CDBS' flavors support in packages that we
>>>currently build multiple times with different configure flags /
>>>CFLAGS / LDFLAGS... (e.g. gtk+, glib, pango, vte...).
>>>Can you point me to a package that uses this mechanism, so I can look
>>>at how it's done? Or in the absence of one, can you explain it to me?
>>Source package libgd2 uses flavors explicitly.
>That's exactly what I needed!
>I'm giving it a try with vte, which builds the source multiple times (a
>normal build, an udeb build, one for each supported python version, and
>now an extra gtk+3 build). It's looks great,
Whoah, sounds like a (too?) good challenge for the flavor feature.
>though it can still be improved a bit:
>- I've seen that you've fixed the "honour
>DEB_CONFIGURE_FLAGS_$(flavor)" bug in git... would be nice to get that
Yes. Will do - although postponing a bit more now to include (easy
parts of) what you uncover here.
>- Currently I need to manually specify the install directory this way:
>DEB_MAKE_DESTDIRSKEL = $(CURDIR)/debian/tmp/@FLAVOR@
>DEB_DESTDIR = $(CURDIR)/debian/tmp/$(cdbs_make_curflavor)/
>Would be nice if that was not necessary (or not that complicated).
Please elaborate. What goes wrong if using the default values?
>There's a FIXME in libgd2/debian/rules about it.
Thanks for reminding me about the FIXME there.
Not sure if we are talking about the same, though: I see only one FIXME
which is about DEB_CONFIGURE_FLAGS, not DEB_DESTDIR?!?
>- Would be useful to be able to specify CFLAGS as CFLAGS_$(flavor),
>the same way as we do with DEB_CONFIGURE_FLAGS_$(flavor). Probably
>other variables like LDFLAGS, etc.
Yes. I'll look into that.
>- I'm currently installing each flavour in debian/tmp/$(flavour),
>then in my debian/*.install files I list what I want in each package.
>This is fine, except that I have e.g.:
>$ cat debian/libvte-common.install
>And I need to repeat the directory without the flavour prefix,
>otherwise things are installed in /main/usr/... That's a bit
True, that's annoying.
dh_install is only simple to use when all nicely laid out ahead.
How about tidying up "by hand" before the binary-install/* targets -
e.g. in the per-package install/* targets?
>However it's really painful for python-vte.install:
>$ cat debian/python-vte.install
>Here it's installing stuff in /python2.5/usr and /python2.6/usr. I
>could change that to
>But when the list of supported python version changes my package
>would become buggy. I could do something hacky on debian/rules, but
>the point is that the prefix are making stuff painful.
The problem here is that the python-autotools.mk snippet uses the flavor
feature: That clashes with explicit use of that same feature.
I believe you should avoid using that snippet and instead provide your
own local mechanism to add PYTHON to DEB_CONFIGURE_SCRIPT_ENV.
Something like flavors being "main-2.5 main-2.6 gtk3-2.5 gtk3-2.6" and
then resolve PYTHON by chopping off *- from each flavor.
If you have ideas to handle it generally I am obviously interested.
>I've thought that it would be cool to have a -pN option to dh_install,
>similar to the patch -pN option :-)
Would be nice. Try propose that to Joey. I suspect he won't like it,
>>No need to cc me directly - sending to the list is enough. If I don't
>>respond, then please simply email again to "poke" me, as I sometimes
>>get overwhelmed by emails and don't get around to respond to them all.
>OK. I CCed you just in case because the list archive was full of spam
Oh. Others have mentioned that too recently. I don't notice it much,
probably because of my local spam filtering.
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: Digital signature
More information about the Build-common-hackers