> IMHO this is the more important one for software that doesn't build > out of the box, binary packages are nice to have but it should be > possible to rebuild those without reinventing the wheel every time. > > What I'd like to see is a collection of binary packages that are > created from a set of recipies (somewhat like what DarwinPorts > does, but without sucking in a second installation of unix). That > way it should be possible to (mostly) automaticly rebuild the > binary packages when new versions of software are released, and > when a new version of Python is released. > > In an ideal world we'd have the same set of software available for > python 2.4, python 2.5 and Apple's python installation. The only > way to get there is by using a toolset that does most of the work, > manually building software and checking that everything still works > is too much work.
I use shell scripts to do such things even though there are far better tools. I like it because the shell is: ubiquitous, doesn't require special tools or configs, is easy to comprehend, and is easy to modify when things (as they always do) break as versions change. <wishful-thinking> It would be nice to have a set of tools like Fink does, only made for building software in place. </wishful-thinking> > Somewhere on the web should be good enough, Google should be able > to find it then :-) I have a .Mac home page I _never_ really use. Sound like a project to go into the queue. That reminds me, I need to do this for my universal PIL build for 2.4 as well lest the formula become lost in antiquity ;-) On Jan 9, 2007, at 3:32, Ronald Oussoren wrote: > > On 9 Jan, 2007, at 12:04, Daniel Lord wrote: > >> Ronald, >> Yes I will. You raise a very good point about reproducibility. >> I'll build a binary distro for those who want to keep it simple. >> But I will also include an archive containing instruction, shell >> scripts, env vars, and steps required to 'curl' the source and >> build it from scratch. > > IMHO this is the more important one for software that doesn't build > out of the box, binary packages are nice to have but it should be > possible to rebuild those without reinventing the wheel every time. > > What I'd like to see is a collection of binary packages that are > created from a set of recipies (somewhat like what DarwinPorts > does, but without sucking in a second installation of unix). That > way it should be possible to (mostly) automaticly rebuild the > binary packages when new versions of software are released, and > when a new version of Python is released. > > In an ideal world we'd have the same set of software available for > python 2.4, python 2.5 and Apple's python installation. The only > way to get there is by using a toolset that does most of the work, > manually building software and checking that everything still works > is too much work. > >> It requires just a bit of tweaking the CFLAGS and LDFLAGS ( for >> gmp) and a one-line patch for the gmpy distro in cvs (1.02) >> >> That would be an ideal things to also put in the Wiki were it not >> in such sorry state. >> I'd like to help with the Wiki, but I don't have the requisite >> time to learn is admin nor do the content justice right now. > > Somewhere on the web should be good enough, Google should be able > to find it then :-) > > Ronald _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
