[vtkusers] VTK Builds on Cygwin

[Mumit Khan]

On Fri, 26 Jan 2001, Sebastien BARRE wrote:

> So it does mean that we can get rid of the good ol' pcmaker now ? :)

Never used it, so don't know if it's good or bad ;-)

I should point out that, that thanks to the VTK authors, there was 
just one single line of Cygwin specific code change in VTK for 
successful Cygwin port, and that line will soon go away in favor of 
autoconf check. The port itself was trivial, but what Bill and I were 
fighting with was an issue with the linker taking gobs of memory 
trying to build the Graphics DLL, and so we had to experiment with 
alternative ways to build the large DLLs.  See the new MakeDLL script 
in CVS for details (it's a trivial script, majority of the lines are 
comments) .

> >   I have only tried the c++ part, but Mumit did the tcl build.
> 
> OK. That's very interesting. Good news.
> I'm a bit skeptical about Python and Java. Porting to Cygwin is not a 
> trivial task (I helped porting Perl 5 to Cygwin), and I'm not aware of 
> Python or Java ports to this specific environment (although I did not 
> search very thoroughly :)).

Now we're getting into murky waters, especially with Java, which is a
closed-source implementation, and we can't just rebuild to use Cygwin
runtime. 

Before we get into the details, here's a bit of elaboration on what
Bill had eluded to regarding Cygwin tools vs Cygwin runtime. When you
build with Cygwin, by default it will use Cygwin POSIX runtime, and
you get a "Unix'y" feel; you can also use the Cygwin tools to build
Mingw applications, which link to MSVC runtime just like MSVC does
and you of course don't have access to POSIX runtime. This is the
so-called "mno-cygwin" mode, and there's some info on it at:

http://www.nanotech.wisc.edu/~khan/software/gnu-win32/mno-cygwin-howto.txt

It's a bit dated, but the basic idea still applies.

Now, let's first deal with the Tcl issue. All of my VTK code is driven
by Tcl (but moving to Python), plus some C++ extensions to interface
to our simulation engine. Unfortunately for Cygwin users, the version
of Tcl/Tk/Tix/itcl etc distributed are quite old -- modified versions
of Tcl/Tk 8.0.4, and that's what you're stuck with unless you port
one of the newer releases to Cygwin. If you can live with these old
Tcl/Tk versions, then everything will build out of the box, assuming
of course you downloaded the Tcl/Tk source packages from Cygwin 
distribution mirrors for the internal headers VTK needs.

Python 2.0 does build under Cygwin with some patches (do a deja or
google search), but thanks to Jason Tishler <Jason.Tishler at dothill.com>,
Python 2.1 will build out of the box with Cygwin.

You can build Java JNI's using Cygwin, but I'm not familiar with how
well that works.

With MinGW, which links to MSVC runtime, you can use the pre-packaged
Tcl/Tk, Python, Java etc and all should work with perhaps a few tweaks.
That's something I'm going to look at at some point, but hopefully
someone else will beat me to it.

> I would be curious to know about some comparisons between both native- and 
> Cygwin- generated DLL's. Did you run the regression tests with the Cygwin 
> build ? Could Mumit run the Sphere Benchmark with both ? What is the size 
> of the build/dll ? I love gcc, but it's much slower than MSVC++, did you 
> notice how much slower it was on a whole build ?

I don't use Windows machines, so it's going to be hard for me to do
the comparison. I did the builds on a Linux cross-compiler, and then
moved it over to a W2k box with lousy graphics (it's a laptop). I
did test the build on the native W2k box just to be safe.

If someone wants to test binaries, I'll make those available via ftp.
You'll have to have base Cygwin 1.1.7, plus a few other packages such
as Tcl/Tk installed to get it to run of course. All can be done via
the net from http://www.cygwin.com/ using the network setup program.

Integer performance of the two compilers are comparable, but MSVC does
better on floating-point code generation, so expect some slowdown. May
or may not be noticable depending on what you're doing. GCC 3.0 will
have a new x86 instruction scheduler that will narray, if not remove,
the performance gap.

Regards,
Mumit