why doesn't worksrcdir do what I mean?

[Bayard Bell]

I've noticed that setting worksrcdir to have post-fetch activities use a subdirectory of the fetched source doesn't really work with at least some of the SCM-based fetch methods because worksrcdir is interpolated into worksrcpath, and source is retrieved into worksrcpath, or this at least is the behaviour for git and hg (cvs and svn retrieval seem to work alright, but it seems that retrieving from svn means a slightly different problem, resulting in worksrcdir frequently being set to trunk). I haven't had a chance to play around with the git side, but the problem with mercurial is that clone operations have to be against the top-level of the repository, and if that directory isn't the working directory for the build, worksrcdir, which seems the way to do this, just means that the directory in which I need to work ends up being no less far down in the retrieved tree.

Is there any way to make this work?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1515 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20110403/14dd07cd/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20110403/14dd07cd/attachment-0001.bin>