[Build-common-hackers] pd-pkg-tools

[Jonas Smedegaard]

Hi IOhannes,

(sorry for the lat response :-(  )

On Fri, Dec 03, 2010 at 04:25:30PM +0100, IOhannes zmölnig wrote:

>first of all: is this really the official mailinglist for cdbs?
>looking at the archives, it contains about 80% spam...

Yeah.  Others mentioned this too recently.  Personally I wasn't even 
aware of this problem - probably because my private spam filter works 
properly and I don't use the web interface for the list. :-P


>i'm part of the pkg-multimedia team, where i'm mainly concerned with 
>packaging puredata (aka pd; a graphical real-time language for 
>audio/media processing) related libraries. jonas smedegaard is part of 
>that team too, and he has a strong tendency to push people towards 
>cdbs.
>
>so i eventually started using cdbs (a bit :-))

Yeah!


>now since there are loads and loads of small pd-libraries that need 
>packaging, the idea arose to have some of the work offloaded into a 
>centralized system.
>thus is started a package pd-pkg-tools (modelled after ruby-pkg-tools) 
>to provide this centralized infrastructure.
>i started with some small cdbs snippets, and put that into my 
>repository at github: https://github.com/umlaeute/pd-pkg-tools
>
>jonas immediately turned the idea of this package down, and instead 
>suggested to try incorporating those snippets directly into cdbs.
>
>so here i am.

Welcome!

I would be happy to adopt your code and include it as integral part of 
CDBS.

Even better, however, would be if you could be persuaded to join and 
help maintain it yourself.  Our list is (apart from the spam, 
apparently) pretty quiet.


>jonas, you have comments on my coding style :-)


Licensing header refer to FSF postal address.  Better to refer to their 
website - that's how they do themselves nowadays.


don't check for debhelper.mk - that cause the snippet to require 
specific load order, which is bad.  Instead make targets depending on 
debhelper.mk targets, which then get picked up if debhelper is included.


The comment about code not being specific to other snippets is wrong: 
binary-strip-IMPL/% targets are picked up via other debhelper targets.


The variable $(nostrip_package) has a high risk of clashing with user 
environment: Pick a CDBS-specific name instead - e.g. 
$(cdbs_pd_nostrip_package) - or if sensible to reuse across snippets 
then perhaps $(cdbs_nostrip_package) instead.


There is a test for $(is_debug_package) in an ifeq construct.  That 
won't ever succeed, because ifeq is resolved before that variable is 
defined, and (because it is defined with = not := ) the variable is 
resolved only when used, i.e. inside build targets.

Generally ifeq constructs should be avoided as much as possible, as 
should := definitions, as both tend to cause order of snippet inclusions 
to matter, which is bad: Confusing for the end-user at best, and causing 
impossible circular ordering dependencies at worst.


CDBS_BUILD_DEPENDS_class_pd and CDBS_BUILD_DEPENDS_class_puredata is 
resolved dynamically.  I dislike this, as the intend for these is to 
allow the end-user to suppress specific build-dependencies, and if 
dynamically respolved they are not really specific any longer.

If it is related to (unfinished) auto-resolving package-specific 
dependencies, then I recommend putting it in a separate variable from 
the snippet-specific dependencies.

...or perhaps I just can't imagine the sane use of that approach.



But all this is relatively minor things.  Let's include it, so you can 
start use it - and improve on it as we hack along.

So the question remains: Should I take over from here, or will you do 
it?



Regards,

  - 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/20101223/a93d80e6/attachment.pgp>