On Mon, May 13, 2013 at 1:55 PM, Stuart Hughes <[email protected]> wrote: > Hi Mike, > > In general the packages installed into /opt/ltib/usr/bin are regular and > can be see as extensions to the host system. > > If you're building something that runs on the host, but is sensitive to > the platform/toolchain etc then in the past it's been put into > $PROJECT_DIR/bin/... For example the host gdb that is built is put > there as it would be different depending on whether you're building ARM, > PowerPC etc (and indeed the particular toolchain). > > So if the host-python could only really be built one way, then it is > okay to put it into the /opt/ltib/... bucket. Otherwise maybe it's > better under bin (in the ltib project you're building).
Thanks for the clarification. I am pretty confident that the host python is pretty vanilla and does not depend on any target configuration, hence the result was to carve it out to it's own spec file. I have more patches that ride on top of this as hinted in the previous message, mod_python, wsgi, libxml bindings, etc. They have all worked out very well, and have our production software using these. I could even mange a bump to v2.6 if there is enough of a desire. > Regards, Stuart > > > On 13/05/13 11:41, Mike Goins wrote: >> The existing python.spec file builds a localized version of python to >> do the cross-compile, then it is tossed. This works just fine, but >> other packages could use or need a "host" python that matches the >> cross-built: mod_wsgi, libxml python bindings, mod_python. Using the >> native python installation to build these poses problems, particularly >> 64-bit hosts. >> >> python-host-enable.patch: >> 1. Adds a python-host.spec file that builds and installs a 32 bit >> version of python for the host. >> 2. python.spec updated to detect whether host python is installed and >> uses it, else it maintains the current behavior. >> >> python-2.4.4-linux3.patch. >> This is only incidental to the issue, but included since I have not >> uploaded this to the GPP. This enables python builds on Linux 3.x >> systems. Fairly trivial. >> >> Feedback welcomed, as there are operations that I am not sure if good >> practices, like >> >> #test if there is ltib installed python >> if [ ! -e $DEFPFX/usr/bin/python ]; then >> >> I wasn't sure if there was a better way than just check if it is there. >> >> >> >> _______________________________________________ >> LTIB home page: http://ltib.org >> >> Ltib mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/ltib >> _______________________________________________ LTIB home page: http://ltib.org Ltib mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/ltib
