[tahoe-dev] Trouble compiling on OSX

Brian Warner warner at lothar.com
Sun Aug 7 03:03:54 UTC 2011

On 8/4/11 3:14 PM, Olaf TNSB wrote:
>> Therefore, people who redistribute tahoe-lafs in some container which
>> isn't a darcs repository should include a src/allmydata/_version.py
>> with it. If they don't, you'll get "version == 'unknown'". Those
>> tests that you saw fail are there to make sure that someone isn't
>> running a Tahoe-LAFS build with "version == 'unknown'". :-)
> I think the problem is that when someone (i.e. me!) gets the code from
> the repo but doesn't have darcs. In that case would _version.py be
> populated?

Nope, a git checkout doesn't include the _darcs/* metadata that would
allow /usr/bin/darcs to calculate a version number, even if you had
darcs installed and on your $PATH.

The root problem is that the git mirror is slightly insufficient: to use
it successfully, you have to do some manual work that darcs checkouts
don't need. What I do is to copy the _version.py file out of a built
darcs tree into the same place in my git checkout. The version number
will be stale, but it's enough to pass the (too-stringent, in my
opinion) darcs-based do-I-have-a-sane-version-number-? tests.

> I get the feeling I am just hitting a complete edge case that is
> _really_ rare. What are the odds of someone getting the code from the
> repo _without_ having darcs. Most people without darcs would prob be
> getting pre-packaged code.

Yeah, the general idea is that we handle two cases:

 1: darcs checkout: /usr/bin/darcs can compute the version on each build

 2: tarball: the tarball includes a pre-generated _version.py, and since
             there's no version-control metadata (i.e. _darcs/)
             provided, there's no way to update it, so the _version.py
             remains accurate

and then "git checkout" is only halfway supported.


More information about the tahoe-dev mailing list