Ian Bicking wrote:
I'm thinking that the Sugar jhbuild should probably use
virtual-python.py: http://peak.telecommunity.com/dist/virtual-python.py
Alternately (and particularly if OLPC goes to Python 2.5), Python
should be built as part of the build process. virtual-python
basically symlinks Python so it doesn't pick anything up from the
global installation. It's like building a custom Python, but faster
since it doesn't actually build anything.
I tend to think we should build our own python. The 2.5 migration will
happen at some point and we can't rely on distribution shipping the
python version we want.
sugar-jhbuild can build python already. The problem is that we still
depend on some system installed bindings. dbus and avahi that I can
think of. Both runs a system daemon, so I'm not sure about the best way
to deal with them.
Then instead of relying on $PYTHONPATH to control the environment,
using build/bin/python will use the custom environment. (And of
course, having that directory first on $PATH will make "python" work
as well.)
Would building 100% of the OLPC software be prohibitive (either to
build the software, or setup the build process)? That would then give
us a completely accurate system and process.
I guess it depends on what you mean with 100% of the software. There are
packages that needs to be provided by the system (the dbus system
server for example) and packages that are probably not interesting to
build (libjpeg for example). We need to draw a line. I think current
jhbuild + python would a pretty good line.
Marco
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
