[Bf-committers] MacOS Compile Solved - WARNING

[Ton Roosendaal]

Hi,

C code doesnt support name spaces.

I've done all Blender ports in the past, and only in 2 occasions had to  
solve a name conflict. It's pure overkill to change Blender just for  
improper usage of Quicktime libs in Blender.

Right now don't have time to look at this problem... it's still just a  
matter of properly removing quicktime libs and calls from blender code,  
and write a wrapper for it in the audio or movie lib itself.

Quick hack: copy the aiff.h to aiffx.h, and rename ID in it to ID_ or  
so...

After the conf & when 2.3 is a bit mature I will upgrade to new OSX  
too. Then the problem will be at my workstation as well... so you bet  
it will be fixed then! :)

-Ton-



On Tuesday, Oct 21, 2003, at 23:17 Europe/Amsterdam, Douglas Toltzman  
wrote:

> On Tue, 21 Oct 2003, Douglas Bischoff wrote:
>> On Saturday, September 27, 2003, at 08:55 AM, Douglas Toltzman wrote:
>>
>>> I suppose we'd have to include #ifdefs to protect the entire mess  
>>> from
>>> compilers that don't support namespaces.  However, the QT code is
>>> obviously localized to two environments (Win32 and Mac).  I'm  
>>> thinking
>>> it
>>> can be done in such a way that future conflicts can be avoided.
>>
>> Hello, Doug:
>>
>> Well, it seems that the problem has come back, and you were the only
>> person who ever expressed any interest in how to solve it.
>
> Well, I did do some testing and I discovered that useing a namespace
> adds an additional symbol (the namespace name) to each symbol in the  
> load
> table.  This means that we'd have to create a blender namespace,  
> because
> if we put the Quicktime headers into a qt namespace, the libraries  
> will no
> longer link/load with our code; unless, of course, we could also  
> recompile
> the QT libraries, which is beyond our scope of control.
>
> Hence, the namespace support in the C++ compiler would allow us to  
> declare
> all of the C++ classes, etc. of the blender code in our own namespace,
> hence protecting us from any collision, ever.  But, I don't think Ton,  
> or
> anyone else would want to touch every source file for such a "trivial"
> problem.  I guess you'd like this onto killing a roach with a tactical
> nuclear weapon.
>
> Someday, everyone should declare their classes in a private namespace  
> to
> avoid name collisions.  In the meantime, we'll have to find a more
> creative solution.  BTW: I just finally purchased OS X v10.2 so I could
> setup a Blender build environment and have a look at this.   
> Previously, I
> only had the 10.1 tools and I had little or no time to spend on Blender
> development.
>
> I do think this problem can be resolved without too much wrangling,  
> but it
> may take me some time to get my Mac setup with all the pre-reqs for
> Blender builds.
>
> Douglas Toltzman
>
> p.s. I hope you don't mind that I cc'd the list.  I had meant to post  
> the
> results of my testing, but it slipped through the cracks.
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org  
http://www.blender.org