help needed with python package for mxe-octave

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

help needed with python package for mxe-octave

John W. Eaton
Administrator
I'm trying to update the version of osmesa we use in mxe-octave.

Building is failing with

/scratch/jwe/mxe-octave/default/w32/usr/bin/python
src/mesa/main/format_pack.py src/mesa/main/formats.csv >
build/windows-x86-debug/mesa/main/format_pack.c
Traceback (most recent call last):
   File "src/mesa/main/format_pack.py", line 2, in <module>
     from mako.template import Template
ImportError: No module named mako.template
scons: *** [build/windows-x86-debug/mesa/main/format_pack.c] Error 1
scons: building terminated because of errors.
/scratch/jwe/mxe-octave/default/w32/Makefile:835: recipe for target
'build-only-osmesa' failed
make[1]: *** [build-only-osmesa] Error 2
make[1]: Leaving directory '/scratch/jwe/mxe-octave/default/w32'

Note we are building a copy of Python for use during the build and it's
missing this package that is now required to build osmesa.  What's the
right way to build this package for the version of Python we are using?

Thanks,

jwe

Reply | Threaded
Open this post in threaded view
|

Re: help needed with python package for mxe-octave

Mike Miller-4
On Thu, Sep 28, 2017 at 18:24:52 -0400, John W. Eaton wrote:
> Note we are building a copy of Python for use during the build and it's
> missing this package that is now required to build osmesa.  What's the right
> way to build this package for the version of Python we are using?

I haven't had a chance to try it myself, but I imagine it would need a
new src/python-mako.mk pulling from https://pypi.python.org/pypi/Mako
and building and installing with "python setup.py install". I see that
Mako depends on MarkupSafe, so the same for that package.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: help needed with python package for mxe-octave

John W. Eaton
Administrator
On 09/29/2017 02:13 AM, Mike Miller wrote:
> On Thu, Sep 28, 2017 at 18:24:52 -0400, John W. Eaton wrote:
>> Note we are building a copy of Python for use during the build and it's
>> missing this package that is now required to build osmesa.  What's the right
>> way to build this package for the version of Python we are using?
>
> I haven't had a chance to try it myself, but I imagine it would need a
> new src/python-mako.mk pulling from https://pypi.python.org/pypi/Mako
> and building and installing with "python setup.py install". I see that
> Mako depends on MarkupSafe, so the same for that package.

Thanks, I'll give it a try.

The reason that I'm doing this is to see whether we can provide an
option to force software rendering.

My idea is that on Unixy systems we would just do an LD_PRELOAD of the
osmesa library.  For MXE native Unixy builds, it seems to me that the
most reliable way to do that is to build osmesa so we know which library
to preload.  For other systems, we might have an option to specify the
library.  I don't know how we would detect it automatically.

Oh Windows systems, I don't know.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: help needed with python package for mxe-octave

Pantxo
John W. Eaton wrote

> On 09/29/2017 02:13 AM, Mike Miller wrote:
>> On Thu, Sep 28, 2017 at 18:24:52 -0400, John W. Eaton wrote:
>>> Note we are building a copy of Python for use during the build and it's
>>> missing this package that is now required to build osmesa.  What's the
>>> right
>>> way to build this package for the version of Python we are using?
>>
>> I haven't had a chance to try it myself, but I imagine it would need a
>> new src/python-mako.mk pulling from https://pypi.python.org/pypi/Mako
>> and building and installing with "python setup.py install". I see that
>> Mako depends on MarkupSafe, so the same for that package.
>
> Thanks, I'll give it a try.
>
> The reason that I'm doing this is to see whether we can provide an
> option to force software rendering.
>
> My idea is that on Unixy systems we would just do an LD_PRELOAD of the
> osmesa library.  For MXE native Unixy builds, it seems to me that the
> most reliable way to do that is to build osmesa so we know which library
> to preload.  For other systems, we might have an option to specify the
> library.  I don't know how we would detect it automatically.
>
> Oh Windows systems, I don't know.
>
> jwe

In this bug report [1], JohnD already showed he was able to build a *mesa*
based opengl32.dll for software rendering. Using Qt toolkit this library
produces a few errors (that are still unidentified) but "works" for
on-screen rendering.

Now when it comes to off-screen rendering, we have pretty much the same
problems with native (or vendor specific) and mesa based opengl32.dll:
"glGetIntegerv(GL_VIEWPORT, vp)" returns huge numbers and gl2ps returns with
error.

Pantxo
[1] http://savannah.gnu.org/bugs/?44338



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html