Hi Mike, Sounds good to me. Free free to add this, but not to the default list in config/platform/host/ltib.prefconfig.
Usually, most .spec files should work whether for the host or a target board (that's the aim). There are a few exceptions (such as rpm-fs) though. I've read this at speed, so forgive me if I've missed anything. Regards, Stuart On 14/05/13 01:44, Mike Goins wrote: > 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 > _______________________________________________ LTIB home page: http://ltib.org Ltib mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/ltib
