dr at jones.dk
Thu Dec 23 01:42:42 UTC 2010
(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
>so i eventually started using cdbs (a bit :-))
>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
>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.
I would be happy to adopt your code and include it as integral part of
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
* 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
Size: 836 bytes
Desc: Digital signature
More information about the Build-common-hackers