[Bf-committers] Mac OS X status

[Ton Roosendaal]

Hi,


> This would however mean that users have to
> install yet another seperate package in order to be able to import  
> VRML2
> files. Are there any objections to this approach

Only when they want to import vrml2? Or to use Blender?
In the latter case that's not acceptable...

The vrml2 implementation is monstreous. I dont mind dropping this, and  
start over doing it all right, within a Python project.

-Ton-


> sgefant
>
> On Sunday 22 December 2002 00:29, Maarten Gribnau wrote:
>> Hi LarstiQ,
>>
>> Now that I have messed with it for a few hours I understand the idea.
>> On osx, I have created a work-around that overrides the NAN_PYTHON
>> setting to point to the python that comes with osx. I did this two
>> hours ago, talk about timing...
>>
>> The NAN_MXTEXTTOOLS works fine once NAN_PYTHON is set but I do not
>> really like to override the default. However, I don't think the  
>> current
>> solution is a major problem (apart from being a bit messy). The bigger
>> problem is that I get a link error when I try to link the
>> mxTextTools.so. The file is found but can not be linked. Here is the
>> message:
>> "ld:
>> /usr/local/lib/python2.2/site-packages/mx/TextTools/mxTextTools/
>> mxTextTools.so is input for the dynamic link editor, is not  
>> relocatable
>> by the static link editor again"
>>
>> My knowledge of static versus dynamic linking in combination with GCC
>> is not so good. Do you have a clue?
>>
>> Maarten
>> PS1 About the reason people report problems: I don't think many people
>> try the VRML2 import and you don't have a problem if you don't try.
>> PS2 In the long run it would be better to replace the python importer
>> with a C/C++ version that can be linked to Blender (as was planned
>> before NaN went down). I think the current design is far too complex.
>>
>>> Sorry for the delay in responding, mail-backlog.
>>>
>>> I held a rather long rant on the issue, no one replied to that, and
>>> Kent
>>> committed a while later as it did the job on our systems. I did state
>>> the
>>> solution wasn't optimal at the time, and it still isn't (importing it
>>> from
>>> within python or some such is still the way imho, but please read my
>>> original post).
>>>
>>> Having said that, I do see a problem with the current
>>> NAN_PYTHON_BINARY,
>>> it depends on the fact that NAN_PYTHON contains a working python
>>> binary,
>>> which it does if you set it to /usr, which quite some people did/do
>>> because
>>> they want to reuse existing headers and libraries, not copy  
>>> everything
>>> to the build tree again. Of course, this doesn't work if you don't do
>>> that and keep the default of $LCGDIR/python and don't have a real
>>> python
>>> installation there. Stupid, stupid, in my tests I kept setting
>>> NAN_PYTHON so that didn't show up :(
>>>
>>> Anyway, a quick workaround is to just set NAN_MXTEXTTOOLS
>>> yourself, but it seems people don't run into mxTextTools problems
>>> anymore ? Wonder how they do vrml imports :)
>>>
>>> <snip>
>>>
>>> LarstiQ
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://www.blender.org/mailman/listinfo/bf-committers
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://www.blender.org/mailman/listinfo/bf-committers
>
> --  
> I don't want to look like a weirdo.  I'll just go with a muumuu.
>
> 		-- Homer Simpson
> 		   King-Size Homer
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org