[vtkusers] Migration to VTK6

David Gobbi david.gobbi at gmail.com
Fri Dec 11 08:27:09 EST 2015 

Hi Arno,

Using the macosx10.11 SDK is fine as long as it allows you to set this
desired deployment target.  So if you are able to compile with the
following settings, then the result should run on OS X 10.7:

CMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.7
CMAKE_OSX_SYSROOT:STRING=macosx10.11

I'm not sure how far back you can set the deployment target with this SDK,
but if the 10.7 target doesn't compile, you can try 10.8 or 10.9.

If if gives errors for the AGL.framework, then make sure that your code has
no calls to Carbon APIs.

 - David

On Fri, Dec 11, 2015 at 12:48 AM, Arno Klein <binarybottle at gmail.com> wrote:

> Thank you for clarifying this for me!!
>
> When I set the SDK to 10.9:
> SET(CMAKE_OSX_SYSROOT "macosx10.9")
>
> I get the error:
> clang: warning: no such sysroot directory: 'macosx10.9'
>
> I don't get this error when I set the SDK to 'macosx10.11', but would this
> setting place an unreasonable demand on the target architecture?
>
> Cheers,
> @rno
>
> On Thu, Dec 10, 2015 at 11:09 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
>
>> Ah, so you're building a binary package to share with others. I strongly
>> advise against using these:
>>
>> SET(CMAKE_OSX_DEPLOYMENT_TARGET "")
>> SET(CMAKE_OSX_SYSROOT /)
>>
>> The resulting binary will only work with your own version of OS X or
>> later.  Your best bet is to name a reasonably old deployment target (e.g.
>> 10.7) and SDK (e.g. 10.9).
>>
>> CMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.7
>> CMAKE_OSX_SYSROOT:STRING=macosx10.9
>>
>> These will provide a binary package that will work on 10.7 or later.
>>
>> What is the minimum supported OS X that the anaconda VTK supports?
>> Ideally, you should use that version as your deployment target.
>>
>> As for AGL, it might be missing from some SDKs because it is obsolete
>> (modern programs should not be using it).  However, it is in my 10.9 SDK,
>> so it will probably also be in yours.
>>
>>  - David
>>
>>
>> On Thu, Dec 10, 2015 at 11:57 PM, Arno Klein <binarybottle at gmail.com>
>> wrote:
>>
>>> I forgot to mention that the other reason for not explicitly setting the
>>> version of OSX in the CMakeLists.txt file is because when I do set it
>>> appropriately (as you suggested), compilation inexplicably raises the
>>> following error, suggesting that outdated SDKs are required:
>>>
>>> make[2]: *** No rule to make target
>>> `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/AGL.framework',
>>> needed by `travel_depth/TravelDepthMain'.  Stop.
>>>
>>> Cheers,
>>> @rno
>>>
>>> On Thu, Dec 10, 2015 at 10:46 PM, Arno Klein <binarybottle at gmail.com>
>>> wrote:
>>>
>>>> I built VTK 6 through the Anaconda Python distribution ("conda install
>>>> vtk" installed 6.3).
>>>>
>>>> I placed the three lines you recommended in the top-level
>>>> CMakeLists.txt file in my library:
>>>> SET(CMAKE_OSX_DEPLOYMENT_TARGET "10.11")
>>>> SET(CMAKE_OSX_ARCHITECTURES "x86_64")
>>>> SET(CMAKE_OSX_SYSROOT "macosx10.11")
>>>>
>>>> This enabled the make command to compile farther than I have been able
>>>> to get so far.  However, it requires someone to explicitly specify which
>>>> version of MacOSX, which I was hoping to avoid.  Previously, I was using:
>>>>
>>>> #https://forums.developer.apple.com/thread/17334
>>>> SET(CMAKE_OSX_DEPLOYMENT_TARGET "")
>>>> SET(CMAKE_OSX_SYSROOT /)
>>>>
>>>> or:
>>>>
>>>> # https://cmake.org/Bug/view.php?id=14695
>>>> SET(MACOSX_DEPLOYMENT_TARGET
>>>> ${DARWIN_MAJOR_SDK_VERSION}.${DARWIN_MINOR_SDK_VERSION})
>>>> SET(CMAKE_CXX_FLAGS "--sysroot ${CMAKE_OSX_SYSROOT} ${CMAKE_CXX_FLAGS}")
>>>>
>>>>
>>>>
>>>> Cheers,
>>>> @rno
>>>>
>>>> On Thu, Dec 10, 2015 at 10:14 PM, David Gobbi <david.gobbi at gmail.com>
>>>> wrote:
>>>>
>>>>> Actually I might have misunderstood your issue.  Did you build VTK 6
>>>>> yourself, or did you download a binary package?  In either case, the three
>>>>> cmake variables that I mentioned above should be set the same in your own
>>>>> project as they are in the VTK that you are building against.
>>>>>
>>>>> On Thu, Dec 10, 2015 at 11:00 PM, David Gobbi <david.gobbi at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> You can try setting the SDK info in the CMakeCache.txt:
>>>>>>
>>>>>> CMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.11
>>>>>> CMAKE_OSX_ARCHITECTURES:STRING=x86_64
>>>>>> CMAKE_OSX_SYSROOT:STRING=macosx10.11
>>>>>>
>>>>>> I recommend deleting your entire build directory, creating a new
>>>>>> CMakeCache.txt that has only these three lines, and then re-running cmake.
>>>>>>
>>>>>>  - David
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 10, 2015 at 10:49 PM, Arno Klein <binarybottle at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> 'gcc tmp.cpp' created an 'a.out' file, and I have been able to
>>>>>>> compile other things, so I guess my Xcode installation is fine.  What do
>>>>>>> you recommend I try next?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> @rno
>>>>>>>
>>>>>>> On Thu, Dec 10, 2015 at 7:52 PM, David Gobbi <david.gobbi at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> The header unistd.h is posix standard and comes with every Xcode
>>>>>>>> SDK.  Try compiling the following trivial program.  If it doesn't compile,
>>>>>>>> then there must be something awry with your Xcode installation:
>>>>>>>>
>>>>>>>> #include <unistd.h>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>   return 0;
>>>>>>>> }
>>>>>>>>
>>>>>>>>  - David
>>>>>>>>
>>>>>>>> On Thu, Dec 10, 2015 at 7:39 PM, Arno Klein <binarybottle at gmail.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Thank you for your help!
>>>>>>>>>
>>>>>>>>> I am now able to compile with cmake on linux, but get the
>>>>>>>>> following error on macosx 10.11, even though there is no "unistd.h"
>>>>>>>>> anywhere in my github repo (
>>>>>>>>> https://github.com/nipy/mindboggle/issues/69):
>>>>>>>>>
>>>>>>>>> Scanning dependencies of target FsSurfaceReader
>>>>>>>>> [ 3%] Building CXX object
>>>>>>>>> CMakeFiles/FsSurfaceReader.dir/FsSurfaceReader.cpp.o
>>>>>>>>> In file included from
>>>>>>>>> /software/mindboggle/surface_cpp_tools/FsSurfaceReader.cpp:13:
>>>>>>>>> In file included from
>>>>>>>>> /software/mindboggle/surface_cpp_tools/FsSurfaceReader.h:16:
>>>>>>>>> In file included from /usr/local/include/vtk-6.0/vtkPolyData.h:58:
>>>>>>>>> In file included from /usr/local/include/vtk-6.0/vtkPointSet.h:30:
>>>>>>>>> In file included from /usr/local/include/vtk-6.0/vtkDataSet.h:41:
>>>>>>>>> In file included from
>>>>>>>>> /usr/local/include/vtk-6.0/vtkDataObject.h:36:
>>>>>>>>> In file included from /usr/local/include/vtk-6.0/vtkObject.h:42:
>>>>>>>>> In file included from
>>>>>>>>> /usr/local/include/vtk-6.0/vtkObjectBase.h:44:
>>>>>>>>> In file included from /usr/local/include/vtk-6.0/vtkIndent.h:25:
>>>>>>>>> In file included from
>>>>>>>>> /usr/local/include/vtk-6.0/vtkSystemIncludes.h:36:
>>>>>>>>> In file included from /usr/local/include/vtk-6.0/vtkIOStream.h:33:
>>>>>>>>> In file included from
>>>>>>>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iostream:37:
>>>>>>>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__config:23:10:
>>>>>>>>> fatal error:
>>>>>>>>> 'unistd.h' file not found
>>>>>>>>> #include
>>>>>>>>> ^
>>>>>>>>> 1 error generated.
>>>>>>>>> make[2]: ***
>>>>>>>>> [CMakeFiles/FsSurfaceReader.dir/FsSurfaceReader.cpp.o] Error 1
>>>>>>>>> make[1]: *** [CMakeFiles/FsSurfaceReader.dir/all] Error 2
>>>>>>>>> make: *** [all] Error 2
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> @rno
>>>>>>>>>
>>>>>>>>> On Thu, Dec 3, 2015 at 6:25 AM, David E DeMarle <
>>>>>>>>> dave.demarle at kitware.com> wrote:
>>>>>>>>>
>>>>>>>>>> I agree with Cory on Update() being redundant before the Write().
>>>>>>>>>>
>>>>>>>>>> >    vtkDataObject* dobj = someAlgorithm->GetOutput(1);
>>>>>>>>>> >    dobj->Update();
>>>>>>>>>>
>>>>>>>>>> should become:
>>>>>>>>>>
>>>>>>>>>>   someAlgorithm->Update(1); //to make sure there is something
>>>>>>>>>> valid
>>>>>>>>>>   vtkDataObject* dobj = someAlgorithm->GetOutput(1); //keep the
>>>>>>>>>> output for later use
>>>>>>>>>>
>>>>>>>>>> Because since vtk6, dobj no longer has any connection to the
>>>>>>>>>> algorithm, so updating it (which used to update the algorithm for you) no
>>>>>>>>>> longer has any meaning.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> David E DeMarle
>>>>>>>>>> Kitware, Inc.
>>>>>>>>>> R&D Engineer
>>>>>>>>>> 21 Corporate Drive
>>>>>>>>>> Clifton Park, NY 12065-8662
>>>>>>>>>> Phone: 518-881-4909
>>>>>>>>>>
>>>>>>>>>> On Thu, Dec 3, 2015 at 9:09 AM, Cory Quammen <
>>>>>>>>>> cory.quammen at kitware.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Arno,
>>>>>>>>>>>
>>>>>>>>>>> That pattern should be valid in VTK6. Are you getting compile
>>>>>>>>>>> errors?
>>>>>>>>>>>
>>>>>>>>>>> I believe the Update() and Write() calls to the writer are
>>>>>>>>>>> redundant - you should need only one.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Cory
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Dec 2, 2015 at 5:56 PM, Arno Klein <
>>>>>>>>>>> binarybottle at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I am trying to update my code to migrate to VTK6 according to:
>>>>>>>>>>>>
>>>>>>>>>>>> http://www.vtk.org/Wiki/VTK/VTK_6_Migration/Removal_of_Update
>>>>>>>>>>>>
>>>>>>>>>>>> According to the examples on that site, I understand that:
>>>>>>>>>>>>
>>>>>>>>>>>>     vtkDataObject* dobj = someAlgorithm->GetOutput(1);
>>>>>>>>>>>>     dobj->Update();
>>>>>>>>>>>>
>>>>>>>>>>>> should become:
>>>>>>>>>>>>
>>>>>>>>>>>>     someAlgorithm->Update(1);
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> However, I don’t know how to deal with the following pattern:
>>>>>>>>>>>>
>>>>>>>>>>>> void PointAreaComputer::WriteIntoFile(char *fileName)
>>>>>>>>>>>> {
>>>>>>>>>>>>     vtkPolyDataWriter* writer=vtkPolyDataWriter::New();
>>>>>>>>>>>>     writer->SetFileName(fileName);
>>>>>>>>>>>>     m_mesh->GetPointData()->SetScalars(m_pointsArea);
>>>>>>>>>>>>     writer->SetInputData(m_mesh);
>>>>>>>>>>>>     writer->Update();
>>>>>>>>>>>>     writer->Write();
>>>>>>>>>>>>     writer->Delete();
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> What should I do to make this compatible with VTK6?
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> @rno
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20151211/8251fe28/attachment.html>

More information about the vtkusers mailing list