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

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

I notice you are already member of the collab-maint group, so that 
should be ok.  You can request to join our "build-common"[1] team as 
well, but really it is unused these days for anything but our 
mailinglist, so only do that for completeness sake.

[1] https://alioth.debian.org/projects/build-common/

Oh, and the most important part:  Please do push your changes to our 
git: git.debian.org:/git/collab-maint/cdbs

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

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

Correct.

>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.
>
>ok.
>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 
>build-dependencies")
>
>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 
time :-P

For now, I'd be happy to elaborate here on the list on any and all parts 
of CDBS.

>> 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.
>
>sounds great.
>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 
>> it?
>>
>
>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
>of C/C++.

No problem.  We take it as we move along.

  - 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/20110104/a690557d/attachment.pgp>