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

Fri Dec 24 03:38:03 UTC 2010

On Thu, Dec 23, 2010 at 10:56:32PM +0000, Emilio Pozuelo Monfort wrote:
>On 21/12/10 22:38, Jonas Smedegaard wrote:
>>On Sun, Dec 19, 2010 at 06:38:52PM +0000, Emilio Pozuelo Monfort 
>>wrote:
>>>I'm now doing
>>>
>>>DEB_DESTDIR = $(CURDIR)/debian/tmp$(if $(findstring
>>>udeb,$(cdbs_make_curflavor)),/udeb)
>>>
>>>Without setting DEB_MAKE_DESTDIRSKEL. It's working great and the 
>>>dh_install issue only affects libvte9-udeb.install, so it's not a big 
>>>deal.
>>
>>Try this instead:
>>
>>DEB_DESTDIR_$(udeb) = $(DEB_DESTDIR)udeb
>>
>>
>>Per-flavor is expanded during build, and per-package during install.
>>
>>They use same "namespace" (string after last slash) so per-flavor 
>>cannot exist during install too as it is currently implemented.
>
>Hmm, that doesn't make any sense to me. DEB_DESTDIR is the directory 
>to pass to `make install` in DESTDIR. It is thus per-flavor, and not 
>per package. So I don't understand how DEB_DESTDIR_$(package) would 
>work. Only DEB_DESTDIR_$(flavor) makes sense to me.

Per-package variables is useful e.g. for an upstream source like veejay 
<http://veejay.dyne.org> containing multiple independent subprojects. 
Each build could then be tied to a target binary package.  No doubt 
needs more work, though (veejay have been on my todo since 2008 when I 
tried and realized it required lots of CDBS improvements).

Don't understand why abusing the clashing namespaces don't work.

>I've applied this to makefile.mk.in:
>
>-cdbs_make_curdestdir = $(cdbs_curdestdir)
>+cdbs_make_curdestdir = $(if $(DEB_DESTDIR_$(cdbs_make_curflavor)),$(DEB_DESTDIR_$(cdbs_make_curflavor)),$(cdbs_curdestdir))

Makes sense.  Here's a more compact way to do the same (untested):

cdbs_make_curdestdir = $(or $(DEB_DESTDIR_$(cdbs_make_curflavor)),$(cdbs_curdestdir))

>And have in vte/debian/rules:
>
>DEB_DESTDIR = $(CURDIR)/debian/tmp
>DEB_DESTDIR_udeb = $(DEB_DESTDIR)/udeb
>
>And that works fine. All flavors install to debian/tmp except the 
>udeb flavor, which installs to debian/tmp/udeb.
>
>What do you think about that?

Looks good to me.

I have now pushed the fix to properly use DEB_MAKE_DESTDIRSKEL.

That gives you an alternative to explicitly setting DEB_DESTDIR: you 
should be able to instead set a conditional skeleton like this:

DEB_MAKE_DESTDIRSKEL = $(cdbs_curdestdir)$(if $(is_udeb),/@FLAVOR@)

...with $(is_udeb) being some check if the current flavor is the udeb.

There is no benefit of that approach for this package, but don't you 
agree it might be handy in more complex cases to compute rather than 
explicitly declare?

Hmmm.  I think it makes good sense to support per-flavor skeletons.  
That might even make it possible to use per-python-version-flavors 
together with other kinds of flavors...

>We may also want to support something like
>
>DEB_DESTDIR = $(CURDIR)/debian/tmp/@FLAVOR@
>
>Maybe something like (untested)
>cdbs_make_curdestdir = $(subst @FLAVOR@,$(cdbs_make_curflavor),$(if $(DEB_DESTDIR_$(cdbs_make_curflavor)),$(DEB_DESTDIR_$(cdbs_make_curflavor)),$(cdbs_curdestdir)))
>
>so you don't have to specify it for each flavor if you want all them 
>in different places (I may want that in e.g. glib2.0, pango1.0, 
>gtk+3.0... I could specify that by hand but this would be nicer)

Yes.  But better to do it via DEB_MAKE_DESTDIRSKEL.

Using DEB_MAKE_*DIRSKEL makes it easier use it in subclasses - as I've 
done with latst commit a moment ago to python-autotools.mk.

Also, @FLAVOR@ should probably only be substituted when flavors are in 
use, not always (just by principle - I can't imagine it going wrong).

>Also it would be nice not automatically expand $(CURDIR) if one just 
>specifies e.g. DEB_DESTDIR = debian/tmp
>
>Not sure if that would break non-autotools packages or anything... 
>Not a big deal in any case.

Hmm.  You are full of good ideas. :-)

Not sure about the consequenses either. let's not do it now - looks too 
complex with too little gain.

>>Perhaps you want to apply it yourself: The packaging is maintained in 
>>the git collab-maint area so you should have write access already.
>
>Sure. I have pushed a few commits and will keep pushing others.

Yes, I noticed.  Just keep pushing :-D

>>And please do help summarize what is still left to do here. An awful 
>>lot of details, and I have lost track of which parts we've solved 
>>along the way here...
>
>Right now, the DEB_DESTDIR_$(flavor) and CFLAGS_$(flavor) for vte. 

I'll try integrate your DEB_DESTDIR_$(flavor) (or my more compact 
variant) with my recent DEB_MAKE_DESTDIRSKEL support.

I'll comment on CFLAGS_$(flavor) in your other mail.

>I'll also look at other packages to see if we need more stuff for 
>them.

Great.

    - 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/20101224/a807c76c/attachment-0001.pgp>