Marco Pesenti Gritti wrote:
Ian Bicking wrote:
So, the other topic about package layout, is if and how OLPC should
use distutils and/or setuptools.
Right now, honestly, I don't understand the Sugar build process (not
jhbuild so much as the sugar package itself). I assume it makes sense
to people familiar with auto* and the configure/make/make install
pattern. Honestly I'm not one of those people, so maybe the current
system handles requirements I'm unaware of.
Anyway, the conventional way to distribute and install a package in
Python is with distutils. This involves a file setup.py in the root
of the package, which describes the package and anything in the build
process (for pure-Python packages it's very short). It handles
compiling extensions as well, but without as much flexibility as
configure, or as efficient as make. But in practice it seems to be
enough flexibility, and certainly enough for OLPC. And you just have
a setup.py file, without any other build-related files, which I
personally appreciate.
Hi,
I can't comment on the technical merits of distutils since I never used
them. Generally everyone hates auto* but as Dan mention it's a very
flexible system.
Anyway the reason we chose automake to start with was:
- All the sugar dependencies use it. There is some value in a consistent
build system for the whole software stack.
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.
- 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.
So yeah, I don't think what Sugar itself uses matters all that much, so
whatever you're all comfortable with. There's a few useful features
using distutils and setuptools, but they aren't anything too magic.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
