Re: [Ltib] Host python patch

[Stuart Hughes]

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 <address@hidden> 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
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/ltib
>>>
> 
> _______________________________________________
> LTIB home page: http://ltib.org
> 
> Ltib mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/ltib
>