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.
- 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)
Marco
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
