[CMake] [Paraview] paraview CVS xcodebuild

[Bill Hoffman]

Mike Jackson wrote:
> 
> 
> 
> On May 8, 2008, at 11:08 AM, Bill Hoffman wrote:
> 
>> Mike Jackson wrote:
>>
>>>> On Thu, May 8, 2008 at 10:42 AM, Sean McBride 
>>>> <sean at rogue-research.com <mailto:sean at rogue-research.com>> wrote:
>>>>
>>>>     On 5/7/08 3:52 PM, jonathan grimm said:
>>>>
>>>>     >paraview CVS xcodebuild is no longer working.  On a Mac Pro 16GB
>>>>     ram with
>>>>     >10.5.  I checked and xcodebuild is a 32 bit executable.
>>>>     >Makefiles work on the same machine.
>>>>     >Is there anything that can be done about this?  The .xcodeproj is
>>>>     only 14
>>>>     >MB.
>>>>
>>>>     Not working how?  It crashes? it's stuck in an infinite loop? what?
>>>>     Which version of CMake?  Of paraview?  Of Xcode?  You're not 
>>>> telling
>>>>     enough for anyone to help.
>>>>
>> Runs out of memory and dies.  I sent stuff to apple a while ago and 
>> they sort of said it was too big.  No one would create something like 
>> this by hand because it is too much work.   Sad part is visual studio 
>> handles projects this size with no problem at all.
>>
>> -Bill
>>
>>
>>
> 
> Did Apple offer any other advice on how to reduce the memory footprint? 
> If it is just the fact of a project file being too large then almost all 
> hope is shot.. but there are a few things to look at.
> 
> 1: Create an Xcode project that uses makefiles instead of its own build 
> system internals but listing all the files may be the problem here.
> 
I think it maybe just listing the files.

> 2: Create the Xcode project that contains project references to 
> subprojects (in the case of paraview, each subdirectory would have its 
> own project file, like vtk, etc). This may make each project file 
> smaller and therefor loadable by Xcode. This does mean that using Xcode 
> now requires lots of windows to be open but that may be the price that 
> is paid for Apples inability to create a project file that scales well.
> 

This is one option.  However, last time I looked at it, there was no way 
to make sure dependent things are built in the correct order using this 
model.

> Now knowing where the problem lies I am just guessing at this point on 
> how to reduce the memory footprint so the Xcode project scales better.. 
> or the CMake team has just found the limit for Xcode and that is how the 
> world works in "Apple Land".
> 
I sort of gave up when I first did the Xcode stuff after a few emails to 
Apple.  I really don't have the time/funding to look into this further. 
  However, if someone else wants to create a bug report for Apple, that 
would be great.

-Bill