Ian Bicking wrote:
I assume at some point distutils installations will be part of the
build system as well, as it is nearly universal in the Python world,
and at some point we'll be using external tools or libraries. I
actually wrote the email after I wanted to install nose
(http://nose.python-hosting.com/) into the environment, and had to
fiddle a little bit to do it.
But, especially with a custom Python build, supporting distutils is
not particularly hard. I assume getting jhbuild to run
"build/bin/python setup.py install" is not hard. It's just any weird
CFLAG stuff that's hard, and I'm guessing that packages already using
distutils will have that worked out in an okay way (knock on wood).
In theory, once this is all worked out, configure won't even be
necessary -- everything will be locked into a known location and for
each new project that is incorporated maybe we'll need to tweak
something here or there but then it's set.
I was actually referring to the build system of the single packages
here. If you want to hack on sugar you will likely have to hack (or at
least understand) some of the dependencies. I'm actually thinking to
sugar as gtk + dbus + matchbox + .... + our python bits, not as the
python code only. In this context using the same build system have some
value.
If you want to write a sugar activity then this probably doesn't matter.
Btw it turns out jhbuild already supports distutils.
- The whole GNOME tools ecosystem is based on auto*. Just think about
jhbuild or pkg-config.
- Sugar will end up being a mix of C and python code.
- We are familiar with it.
Still I think it might bw worth considering distutils as one of the
option for external activities. It might just be easier for people
that are not familiar with auto*. In general I think the bundles
specification should be kept independent from any build system (and I
think it is atm)
I feel reasonably confident that distutils -- and actually moreso
setuptools -- would be the proper basis for making Python-based apps
into bundles. Sugar itself isn't an app, though currently it does
include some apps, so maybe this doesn't apply to Sugar itself.
There will be activities wrote in C, or activities based on application
already using auto*. Getting these to use distutils would not be
productive (if possible at all).
But we are going to have documentation on how to write activities and
bless a build system for activities that are written from scratch in
python (which should be the most common case). setuptools might be a
good candidate for this. It would be positive to think and experiment in
this direction. We want to be really easy to write activities. And I
would never put auto* and really easy in the same phrase :)
Marco
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
