P4D3::Revision hash not displayed in About-box

Issue #26 resolved
Marko Käning
created an issue

The about box doesn't show the mercurial revision key because during build of MacHg the corresponding python scripts doesn't work properly.

This line {{{ #!/usr/bin/python import os, subprocess, re, sys

targetBuildDir = os.getenv("TARGET_BUILD_DIR")

  • print "targetBuildDir: ", targetBuildDir

getChangeset = subprocess.Popen('hg parent --template "{node|short}" --cwd ' + targetBuildDir, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True) }}}

Shows that "targetBuildDir" is actually empty, which causes subsequent steps to fail:

{{{ markos-imac:machg marko$ python /Users/marko/WC/MacHg/build/MacHg.build/Release/MacHg.build/Script-969BDCFD1196844A007AA6D9.sh targetBuildDir: None Traceback (most recent call last): File "/Users/marko/WC/MacHg/build/MacHg.build/Release/MacHg.build/Script-969BDCFD1196844A007AA6D9.sh", line 8, in <module> getChangeset = subprocess.Popen('hg parent --template "{node|short}" --cwd ' + targetBuildDir, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True) TypeError: cannot concatenate 'str' and 'NoneType' objects }}}

Hope this helps to find a solution.

Comments (8)

  1. Marko Käning reporter

    Could trace it back to that the Popen() returns the error message:

    /bin/sh: hg: command not found

    something I was in the end suspecting...

    I don't run a mercurial installed via MacPorts, instead installed it with one of the mpkg installer files available from http://mercurial.berkwood.com/binaries/Mercurial-1.5.2-py2.6-macosx10.6.zip.

    It turns out that


    is a better choice when calling hg here for me.

    If the trailing slash is not appended to targetBuildDir it also messes up, which pointed me to that

    result  = subprocess.Popen('/usr/libexec/PlistBuddy -c "Delete BuildHashKey" ' + infoPlist, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)
    result  = subprocess.Popen('/usr/libexec/PlistBuddy -c "Add BuildHashKey string '+ changeset + '" ' + infoPlist, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)

    do not throw errors if the PlistBuddy-actions could not be carried out as wanted.

    But this case shouldn't happen if getenv() worked properly, i.e. didn't return nothing... (I had this all the time, suddenly it works. Haven't figured out why.)

  2. Marko Käning reporter

    Hi Jason,

    I am still irritated by this issue.

    The changeset hash is now properly extracted by the bundled localhg. No problem here.

    But for some reason I had a couple of cases that during building MacHg the hash wasn't properly written to the plist file. Could not reproduce why it wouldn't be written in these cases, nor could I understand why it worked later. Looks a little similar to my troubles further up in this thread... :(


  3. Jason Harris repo owner
    • changed status to open

    Hmmm... So can you reproduce this repeatedly?

    Can you try the following

    1. Try one time by deleting the build directory and building again
    2. Once built try one time by deleting BuildHashKey from the targeted info.plist

    Are either of these attempts repeatable?

    Thanks! Jas

  4. Marko Käning reporter

    Hi Blake, I can reproduce this changing of style. ;) Perhaps that's even intended! ;)

    Well, apart from that I have to add that I in an erratic manner still get empty hashes, although there is no way to reproduce which conditions must be fulfilled for this to happen.

  5. Log in to comment