why doesn't worksrcdir do what I mean?

[Bayard Bell]

Sorry, here's a fragment of what I was trying:

homepage        http://hub.opensolaris.org/bin/view/Project+pkg/WebHome
fetch.type      hg
hg.tag          ${version}
hg.url          ssh://anon@hg.opensolaris.org/hg/pkg/gate

In this case, what I fetch from Mercurial has a src tree that's the real working directory one level down from the gateway (so ${prefix}/var/macports/build/<conversion of portpath>/work/${distname}/src). Now, I can indeed use configure.dir etc. to work around this. If, however, I compare this to a port like kerberos5, it seems there that one is able to set worksrcdir to ${distname}/src and not have to worry about changing the working directories for subsequent operations. What I'm saying is that worksrcdir seems to end up semantically different if I'm fetching from certain kinds of SCM rather than using other kinds of extracts, requiring me to make other changes. The underlying problem seems to be fetching from some of the SCMs to worksrcpath instead of distpath, where making the two the same thing means when fetching that I have to change the working directory for other operations derived from worksrcdir because of how I'm fetching, where it seems that the working path should be able to be defined distinctly from where the source is fetched rather than made identical to it. I think.

On 3 Apr 2011, at 22:11, Ryan Schmidt wrote:

> 
> On Apr 3, 2011, at 16:06, Bayard Bell wrote:
> 
>> 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?
> 
> It might help if you gave an example (Portfile code) of what you tried, what happened, and what you wanted to happen instead.
> 
> The answer might turn out to be that you shouldn't be changing worksrcdir after all, and that you should be changing configure.dir and/or build.dir instead.
> 
> 

-------------- 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/20110412/f113784a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 841 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20110412/f113784a/attachment-0001.bin>