Re: [Pythonmac-SIG] gmpy universal build (static)?
In article [EMAIL PROTECTED], Ronald Oussoren [EMAIL PROTECTED] wrote: 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. I agree. I'd be nice to have a recipe for any packages on pythonmac.org that aren't trivial to build. (Ditto for eggs, I suppose; I've not yet tried to learn how to make eggs -- binary or otherwise. Any good basic tutorials around?) 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. That sounds wonderful -- publish a script instead of a description of what to do. But even a recipe is much better than nothing. And to that effect...I am willing to serve recipes for building Mac versions of python-related software (I already serve a few). But we're talking basic here, no wiki, no database, each recipe is a page, with one table of contents page, you send me an update when you want to fix or improve something. -- Russell ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] gmpy universal build (static)?
I like most do not like all that DarwinPorts and Fink bring in when you install them. So, I have been developing my own scripts as well. Currently, I use a model for the script based on the actions that DarwinPorts does when it installs packages, but using bash scripts rather than tcl which I never really liked. You may view some of them at http://idisk.mac.com/kranki-Public if you are interested. mkLibexpat.sh is my primary script where I develop new features and then push them back into the other scripts. I have not tried to make any of them universal installations nor have I added binary installs, currently just source installs. I own 7 macs of varying types and running these scripts has really not been much of a burden. Besides, I just didn't feel that I wanted them taking up twice as much harddrive space, but I am not opposed to adding that ability to them if needed. They were written by me and have not had any sort of review by others which I would like. So, even if you do not want to use them, but review them, I would appreciate the feedback. I am going to use them whether anyone else does or not until I find something better. Anyway, they are not copyrighted because they are not that important. However, I do believe that it is important to provide the build scripts being used to create the binaries that are being distributed and to distribute them with the binaries. They provide an educational benefit as well as a potential source of improvements if made available. I would be willing to provide some time to help in creating and maintaining them in collaboration with others. Just let me know. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] gmpy universal build (static)?
On 7 Jan, 2007, at 0:42, Daniel Lord wrote: Then I'll package it up for distribution. If you do that please also post patches and/or instructions on how to build the software. I don't want a second pyOpenGL: there is a for that package on pythonmac.org but nobody has a clue about how that was build and getting it to build is more than a quick tweak (that is, I haven't been able to get it to work with small tweaks but maybe I've just tweaked the wrong knobs). Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] gmpy universal build (static)?
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 smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] gmpy universal build (static)?
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
[Pythonmac-SIG] gmpy universal build (static)?
gmpy universal build (static) I struggled with it for a while, but was finally able to build both gmp and then gmpy as static universal libraries on my Macbook Pro. Dynamic libs are still problematic but I'll try that next. Is this something new or is this 'old hat' and no one cares. The reason I asked is Alex Martelli told me he struggled with it briefly a while back (liek a year ago ;-) and gave up. I finally found some spare cycles (rare for me) and tackled it. I hope I didn't 'reinvent the wheel'. But even so, the exercise was fun fo someone who gets far too little time at development these days. Make check runs fine on the gmp build. The question I have for this what is available as a check for gmpy so I can test this out on Intel and PPC systems to make sure I built it right. Then I'll package it up for distribution. Unless of course, I have indeed 'reinvented the wheel'. In which case I'll just shuffle off quietly...never mind...move along...nothing to see here... ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
