[Build-common-hackers] Using CDBS' flavors mechanism to build packages

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 
>>wrote:
>>>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!

Good.

>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 
>released.

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
>main/usr/share/locale/		usr/share/locale
>main/usr/share/glade3/		usr/share/glade3
>main/usr/share/vte/termcap-0.0	usr/share/vte/termcap-0.0
>gtk3/usr/share/vte/termcap-2.90	usr/share/vte/termcap-2.90
>
>And I need to repeat the directory without the flavour prefix, 
>otherwise things are installed in /main/usr/... That's a bit 
>annoying.

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
>python*/usr/lib/python*/*-packages/gtk-2.0/*
>
>Here it's installing stuff in /python2.5/usr  and /python2.6/usr. I 
>could change that to
>python2.5/usr/lib/python2.5/site-packages/gtk-2.0/ 
>usr/lib/python2.5/site-packages/gtk-2.0/
>python2.6/usr/lib/python2.6/site-packages/gtk-2.0/ 
>usr/lib/python2.6/dist-packages/gtk-2.0/
>
>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, 
though.

>>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

-- 
  * 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
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20101219/a5c2881c/attachment.pgp>