why doesn't worksrcdir do what I mean?

[Ryan Schmidt]

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.