compiling VTK using Xcode

[ilantal]

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

[wrldwzrd89]

You using build instructions here? If you are, the problem's almost certainly these two lines right here:

CMAKE_OSX_ARCHITECTURES:STRING=ppc;i386
export MACOSX_DEPLOYMENT_TARGET=10.4

Neither of those work properly on 10.8. Use instead:

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.

[ilantal]

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.

[wrldwzrd89]

Originally Posted by ilantal

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.

Set JAVA_HOME to where Java 6 lives. That should help. To do that:

export JAVA_HOME=/path/to/JDK6/Home

[ilantal]

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...."?

[wrldwzrd89]

Originally Posted by ilantal

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...."?

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:

/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

[ilantal]

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/3...c-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.

[wrldwzrd89]

Originally Posted by ilantal

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/3...c-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.

A tip for dealing with this: Many build scripts support a clean argument to nuke built classes and stale JARs. Try that.