dr at jones.dk
Tue Jan 4 14:25:39 UTC 2011
On Tue, Jan 04, 2011 at 02:49:45PM +0100, IOhannes zmölnig wrote:
>On 12/23/2010 02:42 AM, Jonas Smedegaard wrote:
>> 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.
>fine with me.
>i'll subscribe to the list (doing so right now)
Excellent. Welcome aboard!
>tell me what other steps are required on my side.
You need write access to collab-maint area of Alioth, where we have our
I notice you are already member of the collab-maint group, so that
should be ok. You can request to join our "build-common" team as
well, but really it is unused these days for anything but our
mailinglist, so only do that for completeness sake.
Oh, and the most important part: Please do push your changes to our
>> 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.
>i changed the name to $(cdbs_pd_common_nostrip_package)
>i don't know exactly about reusability (the check as it is right now
>tests for both the "nostrip" flag or whether we are building
>dbg-libraries (unlikely with pd-externals, acutally)
>so i think it might make sense to move the snippet into buildvars.mk,
>but i am not so literate with cdbs (and its policies) yet, so i leave
>that decision to you.
I am not really knowledgeable about -dbg packages, but I do believe that
nostrip and -dbg are not entirely the same, so should not be tied too
>> 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.
>which reminds me: shouldn't the "is_debug_package" variable be called
>something more CDBS-specific, like "cdbs_is_debug_package"?
>anyhow, since the "is_debug" is currently unlikely to be used by any
>pd-specific package i simply removed the offending line.
...and correct too, off course :-)
>> 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.
>while i have been working with make for ages, it still has some
>mysteries for me :-)
Yeah - I won't claim to be fully knowledgeable on make myself either.
Took me quite some time to figure out order of resolving myself too. :-)
>> 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.
>i modelled these after what i found in the other cdbs snippets.
>probably i did not grasp their intent (but then i have no idea how i
>could have known - at least the documentation doesn't say anything
>about these variables related to "suppressing specific
>i'm quite happy to follow any style- and guide-lines, as long as they
>are made explicit somewhere.
Heh. Thanks for insisting on proper documentation.
I am slow to document, however, so if you insist on it being written
down properly before changing to behave most sanely, it might take some
For now, I'd be happy to elaborate here on the list on any and all parts
>> 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.
>the original idea was to create a seaparate @cdbs_pd@
>variable-expansion in control.in, but eventually i found how easy it
>was to add to @cdbs@ so i used that.
Push, and let's look at it again...
>> 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.
>i pushed all my changes to github,
>please pick it up from there.
Please push yourself. We are a team - it makes most sense that all of
us dive in directly on the same repository, rather than some of us
acting as proxy IMO.
>> So the question remains: Should I take over from here, or will you do
>if you want me in, i'd prefer to do it together.
Sorry if that wasn't clear: I would loooove you in. :-D
>i'm not very fluent in cdbs yet, nor does my make knowledge match that
No problem. We take it as we move along.
* 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