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

[Emilio Pozuelo Monfort]

On 19/12/10 03:15, Jonas Smedegaard wrote:
> On Sun, Dec 19, 2010 at 01:47:48AM +0000, Emilio Pozuelo Monfort wrote:
>> - 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.

Sure. Also the fix for #606703 would be nice. If you give me commit access I can 
push that and maybe fix a few more bugs.

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

It installs in debian/tmp//usr (see the double slash), so all the flavours end 
up in the same directory. That's when I don't specify DEB_MAKE_DESTDIRSKEL or 
DEB_DESTDIR.

Being able to specify the DESTDIR for all the flavours and for some in 
particular would be great, e.g.

DEB_DESTDIR = debian/tmp
DEB_DESTDIR_udeb = debian/tmp/udeb

This would partly solve my dh_install issue.

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

Sorry I meant the TODO:

# Install multiple flavors to separate destinations
# TODO: drop unneeded pkgname from skel (included to minimize transition patch)
DEB_MAKE_DESTDIRSKEL = $(CURDIR)/debian/tmp-$(pkgname)- at FLAVOR@
# TODO: stop setting DEB_DESTDIR when DEB_MAKE_DESTDIRSKEL is actually used
DEB_DESTDIR = $(CURDIR)/debian/tmp-$(pkgname)-$(cdbs_make_curflavor)/


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

Cool, thanks.

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

I've just thought that I can install everything to debian/tmp except for the 
udeb build (since everything produces different files except for the udeb build 
which is similar to the main one but with disabled features, so can't go 
together), so I would only need to do the hack for the udeb.install, which is 
not so bad. I'd need support for installing everything to debian/tmp except for 
one flavour, not sure if DEB_DESTDIR_$(flavour) are respected at the moment.

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

Oh I meant the dh_install issue is annoying. It's perfectly fine to just pass 
PYTHON. No problem not using python-autotools.mk (although that would be nice too).

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

I'll try.

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

If you look at the web archive you will know what I mean ;)

Cheers,
Emilio