[Build-common-hackers] Using CDBS' flavors mechanism to build packages
Emilio Pozuelo Monfort
pochu at debian.org
Sun Dec 19 01:47:48 UTC 2010
Hi Jonas,
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!
> python-xklavier, scenic, morituri, lash and a bunch of sugar packages
> use flavors implicitly through python-autotools.mk.
I have a bunch of those too, but I wanted that used it directly.
> You are quite welcome to post here to the list any question you might
> have with using thise relatively new feature, as I obviously have an
> interest in weeding out any bugs in it and encourage use of it. :-D
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, 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.
- 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). There's a
FIXME in libgd2/debian/rules about it.
- 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.
- 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. 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. I've thought that it would be cool to have a
-pN option to dh_install, similar to the patch -pN option :-)
> 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 :)
Cheers,
Emilio
More information about the Build-common-hackers
mailing list