compiling VTK using Xcode

Discussion in 'Mac Programming' started by ilantal, Dec 19, 2012.

  1. macrumors newbie

    Joined:
    Nov 29, 2012
    Location:
    Haifa, Israel
    #1
    I have a Mac Air OSX 10.8.2 with Xcode 4.5.2 which I am trying to wrap VTK so I can use it within a Java program. This works on both Linux and Windows and I want to extend it to the Mac.
    I use CMake 2.8.9 to Configure and Generate. I get the message that Filter ZLIB is ON which I assume is perfectly OK. Then I use Xcode on VTK.xcodeproj which tries to compile the project. I get errors like
    Run custom shell script 'CMake PostBuild Rules' where CMakeScripts/vtkWrapJava_postBuildPhase.makeDebug doesn't exist.
    This is indeed correct, so such file by that name exists. So how do I get around the problem? How do I tell it that I don't want a post build?

    It seems like this is somehow connected to CMake, but I don't see anything obvious in CMake about a post build phase. CMake seems to have dozens of options so I could easily have one of them set incorrectly. None of them have any obvious connection to a post build phase.
    Thanks,
    Ilan
     
  2. macrumors G4

    wrldwzrd89

    Joined:
    Jun 6, 2003
    Location:
    Solon, OH
    #2
    You using build instructions here? If you are, the problem's almost certainly these two lines right here:
    Code:
    CMAKE_OSX_ARCHITECTURES:STRING=ppc;i386
    export MACOSX_DEPLOYMENT_TARGET=10.4
    Neither of those work properly on 10.8. Use instead:
    Code:
    CMAKE_OSX_ARCHITECTURES:STRING=i386
    export MACOSX_DEPLOYMENT_TARGET=10.8
    Also, VTK and Java 7 don't yet get along - use Java 6 instead.
     
  3. thread starter macrumors newbie

    Joined:
    Nov 29, 2012
    Location:
    Haifa, Israel
    #3
    In the final analysis I couldn't get Xcode to compile properly the Java wrap. Instead I used ccmake and the Unix make and make install. That at least compiled properly.
    As you pointed out Java 7 and VTK don't exactly live together in peace. I got a message saying it was trying to retrograde the 7 back to 6, but the retrograde failed.
    What I need is some way to tell the VTK make to use 6 and not 7.
     
  4. macrumors G4

    wrldwzrd89

    Joined:
    Jun 6, 2003
    Location:
    Solon, OH
    #4
    Set JAVA_HOME to where Java 6 lives. That should help. To do that:

    export JAVA_HOME=/path/to/JDK6/Home
     
  5. thread starter macrumors newbie

    Joined:
    Nov 29, 2012
    Location:
    Haifa, Israel
    #5
    Thank you wrldwzrd89, that was a good idea:

    Set JAVA_HOME to where Java 6 lives. That should help. To do that:
    export JAVA_HOME=/path/to/JDK6/Home

    The problem however is still there. I wonder if it might be because your idea set the path to java, but javac is being used to compile. Is there some sort of "export JAVAC_HOME=/path...."?
     
  6. macrumors G4

    wrldwzrd89

    Joined:
    Jun 6, 2003
    Location:
    Solon, OH
    #6
    Nope. JAVA_HOME refers to the home folder of the JDK - where javac lives (and java, in the JDK's private JRE).

    For me, the correct JAVA_HOME value is:
    Code:
    /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
    
     
  7. thread starter macrumors newbie

    Joined:
    Nov 29, 2012
    Location:
    Haifa, Israel
    #7
    Thanks for the continuing help. Obviously you are correct in that java -version and javac -version give the same result. To check which version is in fact used, I found this:

    http://stackoverflow.com/questions/3313532/what-version-of-javac-built-my-jar

    Then I discovered that an old version of a previously compiled jar file was still hanging around. A stupid mistake, but typical. The error message about the newer Java version is now gone and I'll move on to the next stage.

    BTW, the location of my jdk home is exactly the same as yours. I had found it as a result of your previous note, which was the crucial step I was missing.
     
  8. macrumors G4

    wrldwzrd89

    Joined:
    Jun 6, 2003
    Location:
    Solon, OH
    #8
    A tip for dealing with this: Many build scripts support a clean argument to nuke built classes and stale JARs. Try that. ;)
     

Share This Page