ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2024-12-26 08:01:06 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
90ef111964
tahoe-lafs/misc/build_helpers/build-osx-pkg.sh

60 lines
2.1 KiB
Bash
Raw Normal View History

move build-osx-pkg out to a separate shell script Also remove the duplicate test-osx-pkg (i.e. don't run the test as part of the build, and have the caller do it themselves later).
2015-03-21 21:09:33 +00:00
#!/bin/sh
fix OS-X package version I changed the quotes in _version.py, and this script was sensitive to them.
2016-03-23 09:32:48 +00:00
VERSION=`sh -c "cat src/allmydata/_version.py | grep verstr | head -n 1 | cut -d' ' -f 3" | sed "s/\"//g"`
move build-osx-pkg out to a separate shell script Also remove the duplicate test-osx-pkg (i.e. don't run the test as part of the build, and have the caller do it themselves later).
2015-03-21 21:09:33 +00:00
PWD=`pwd`
OS-X: fix package generation The old scheme depended upon the bespoke pseudo-virtualenv scheme that we cooked up long ago (it copied the entire source tree, bin/tahoe and support/ and all, into the mac .pkg archive). When we moved to real virtualenvs, that broke. This new scheme only installs a populated virtualenv into the archive. It replaces the entry-point bin/tahoe with a script that behaves a lot like the old bespoke script: it inserts a relative site-packages/ into sys.path before importing allmydata.scripts.runner and calling run(). This still depends upon the end-users $PATH having a python that is compatible with the binary modules we've compiled here, and there are three potentially-differing Pythons to worry about (homebrew, python.org installers, and Apple's native /usr/bin/python). We'll have to see if they tend to differ in ways that cause problems (I think the maintainers generally try to avoid that). If that's an issue, the next level up is to use bbfreeze or py2app or something in that category, to ship an entire python, and not just a bundle of libraries.
2016-03-16 19:31:21 +00:00
TARGET="/Applications/tahoe.app"
move build-osx-pkg out to a separate shell script Also remove the duplicate test-osx-pkg (i.e. don't run the test as part of the build, and have the caller do it themselves later).
2015-03-21 21:09:33 +00:00
OS-X: fix package generation The old scheme depended upon the bespoke pseudo-virtualenv scheme that we cooked up long ago (it copied the entire source tree, bin/tahoe and support/ and all, into the mac .pkg archive). When we moved to real virtualenvs, that broke. This new scheme only installs a populated virtualenv into the archive. It replaces the entry-point bin/tahoe with a script that behaves a lot like the old bespoke script: it inserts a relative site-packages/ into sys.path before importing allmydata.scripts.runner and calling run(). This still depends upon the end-users $PATH having a python that is compatible with the binary modules we've compiled here, and there are three potentially-differing Pythons to worry about (homebrew, python.org installers, and Apple's native /usr/bin/python). We'll have to see if they tend to differ in ways that cause problems (I think the maintainers generally try to avoid that). If that's an issue, the next level up is to use bbfreeze or py2app or something in that category, to ship an entire python, and not just a bundle of libraries.
2016-03-16 19:31:21 +00:00
virtualenv osx-venv
osx-venv/bin/pip install .
# The virtualenv contains all the dependencies we need, but the bin/python
# itself is not useful, nor is having it as the shbang line in the generated
# bin/tahoe executable. Replace bin/tahoe with a form that explicitly sets
# sys.path to the target directory (/Applications/tahoe.app). This isn't as
# isolated as a proper virtualenv would be (the system site-packages
# directory will still appear later in sys.path), but I think it ought to
# work.
rm osx-venv/bin/*
cat >osx-venv/bin/tahoe <<EOF
#!/usr/bin/env python
import sys, os.path
up = os.path.dirname
bintahoe = os.path.abspath(__file__)
appdir = up(up(bintahoe))
sitedir = os.path.join(appdir, "lib", "python2.7", "site-packages")
# usually "/Applications/tahoe.app/lib/python2.7/site-packages"
sys.path.insert(0, sitedir)
from allmydata.scripts.runner import run
run()
EOF
chmod +x osx-venv/bin/tahoe
# The venv has a .pth file which allows "import zope.interface" to work even
# though "zope" isn't really a package (it has no __init__.py). The venv's
# python has this site-packages/ on sys.path early enough to process the .pth
# file, and running tahoe with PYTHONPATH=...site-packages would also process
# it, but a simple sys.path.insert doesn't. This is the simplest hack I could
# find to fix it.
touch osx-venv/lib/python2.7/site-packages/zope/__init__.py
cp -r $PWD/misc/build_helpers/osx/Contents osx-venv/Contents
move build-osx-pkg out to a separate shell script Also remove the duplicate test-osx-pkg (i.e. don't run the test as part of the build, and have the caller do it themselves later).
2015-03-21 21:09:33 +00:00
# create component pkg
OS-X: fix package generation The old scheme depended upon the bespoke pseudo-virtualenv scheme that we cooked up long ago (it copied the entire source tree, bin/tahoe and support/ and all, into the mac .pkg archive). When we moved to real virtualenvs, that broke. This new scheme only installs a populated virtualenv into the archive. It replaces the entry-point bin/tahoe with a script that behaves a lot like the old bespoke script: it inserts a relative site-packages/ into sys.path before importing allmydata.scripts.runner and calling run(). This still depends upon the end-users $PATH having a python that is compatible with the binary modules we've compiled here, and there are three potentially-differing Pythons to worry about (homebrew, python.org installers, and Apple's native /usr/bin/python). We'll have to see if they tend to differ in ways that cause problems (I think the maintainers generally try to avoid that). If that's an issue, the next level up is to use bbfreeze or py2app or something in that category, to ship an entire python, and not just a bundle of libraries.
2016-03-16 19:31:21 +00:00
pkgbuild --root osx-venv \
move build-osx-pkg out to a separate shell script Also remove the duplicate test-osx-pkg (i.e. don't run the test as part of the build, and have the caller do it themselves later).
2015-03-21 21:09:33 +00:00
--identifier com.leastauthority.tahoe \
More careful quoting in build-osx-pkg.sh. refs #2393 Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2015-03-24 16:42:27 +00:00
--version "$VERSION" \
move build-osx-pkg out to a separate shell script Also remove the duplicate test-osx-pkg (i.e. don't run the test as part of the build, and have the caller do it themselves later).
2015-03-21 21:09:33 +00:00
--ownership recommended \
OS-X: fix package generation The old scheme depended upon the bespoke pseudo-virtualenv scheme that we cooked up long ago (it copied the entire source tree, bin/tahoe and support/ and all, into the mac .pkg archive). When we moved to real virtualenvs, that broke. This new scheme only installs a populated virtualenv into the archive. It replaces the entry-point bin/tahoe with a script that behaves a lot like the old bespoke script: it inserts a relative site-packages/ into sys.path before importing allmydata.scripts.runner and calling run(). This still depends upon the end-users $PATH having a python that is compatible with the binary modules we've compiled here, and there are three potentially-differing Pythons to worry about (homebrew, python.org installers, and Apple's native /usr/bin/python). We'll have to see if they tend to differ in ways that cause problems (I think the maintainers generally try to avoid that). If that's an issue, the next level up is to use bbfreeze or py2app or something in that category, to ship an entire python, and not just a bundle of libraries.
2016-03-16 19:31:21 +00:00
--install-location $TARGET \
More careful quoting in build-osx-pkg.sh. refs #2393 Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2015-03-24 16:42:27 +00:00
--scripts "$PWD/misc/build_helpers/osx/scripts" \
move build-osx-pkg out to a separate shell script Also remove the duplicate test-osx-pkg (i.e. don't run the test as part of the build, and have the caller do it themselves later).
2015-03-21 21:09:33 +00:00
tahoe-lafs.pkg
# create product archive
More careful quoting in build-osx-pkg.sh. refs #2393 Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2015-03-24 16:42:27 +00:00
productbuild --distribution "$PWD/misc/build_helpers/osx/Distribution.xml" \
move build-osx-pkg out to a separate shell script Also remove the duplicate test-osx-pkg (i.e. don't run the test as part of the build, and have the caller do it themselves later).
2015-03-21 21:09:33 +00:00
--package-path . \
More careful quoting in build-osx-pkg.sh. refs #2393 Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2015-03-24 16:42:27 +00:00
"tahoe-lafs-$VERSION-osx.pkg"
move build-osx-pkg out to a separate shell script Also remove the duplicate test-osx-pkg (i.e. don't run the test as part of the build, and have the caller do it themselves later).
2015-03-21 21:09:33 +00:00
# remove intermediate pkg
rm -f tahoe-lafs.pkg
Reference in New Issue Copy Permalink