DN535509596

Subject: Re: Q: TEA/Windows how does this work? - DN [1]

James Ingham <jingham@leda.cygnus.com> - 11 Oct 1999 - comp.lang.tcl

 Vince,

 I will throw in a word here about the first part, why Cygwin is used
 on Windows.

 Remember first that the build part of the TEA architecture was not
 meant for people who were building Windows only or Mac only
 extensions.  They can just use nmake of MW Project files respectively.
 They probably don't need any of the flexibility that configure
 affords.  For their purposes, we should probably include a sample
 nmake file with the sample Tcl extension, just as I have included a
 sample MW project file (actually, I just sent this to Brent last
 night, so it will show up some time soon...)

 On to the cross developers.  There are a couple of salient points.
 One is that Makefiles themselves are NOT static.  Even the Tcl
 Makefiles change around over time, more so for newer extensions.  So
 using Cygwin means that you can keep the changes all in one place,
 which simplifies the update hassles.

 Of course, someone could cook up a Makefile/Configure to VC++ Makefile
 converter, but this would probably be fragile, and anyway it hasn't
 been done.

 The other issue is that configure/make is more powerful by far than
 nmake.  It can do cool things like cross-compilation, so if I only
 have a lameo Windows box, I can build my Windows distributions on my
 nice Sun box.  Of course VC++ doesn't support this but...

 Using Configure/Make also allows one to use gcc, which is free, and at
 this point generates better code than VC++.  Scriptics does not
 officially support this at present, but it is how we build all our Tcl
 apps at Cygnus (see the Insight sources for example Makefiles at
 http://sourceware.cygnus.com).  It is also how George does his BLT
 makefiles last I looked.  Gcc does support cross compiling too!

 If we stuck to nmake, we would also be stuck with VC++...

 And of course, in some cases your extension may need more
 configuration power than just a list of files & dependencies.  GDB is
 a good example of this, since the same source can be built to target
 many different processors.  Configure/Make gives us the power to build
 up this system, and then share it across Unix & Windows.  If we had to
 duplicate this effort, we would go crazy - if it could even be done
 with nmake.  This is perhaps an extreme example, but I am sure there
 are other cases where you play tricks with configury on Unix, and
 don't want to duplicate the effort on Windows.

 For these reasons we decided to use Configure & Make at the TEA
 summit.  The documentation needs to be better set up, so it is easier
 for you to make all this work.  It would also be cool to get the gcc
 changes back into the Scriptics tree.  We have not finished
 incorporating the latest Tcl8.2.x into our source tree, which is why
 we have not submitted our changes yet.  This is kind of a background
 job for us right now, but we will get around to it.

 But I think that the system is workable, and provides a lot of
 simplification for people who are building extensions on Unix &
 Windows.

 Hope this helps some...

 Jim

 BTW, the reason that MacOS is not included in all the TEA discussions
 is that there is no Cygwin on MacOS.  Cygnus used to have a setup that
 would take configure.in and Makefile.in files and use MPW scripts to
 munge them into MPW makefiles, but it was pretty hideous, and fragile.
 We really don't want to go there...  So for now, we will have to
 recode stuff on the Mac.  Actually, I don't even think that a Tcl
 based Project File generation mechanism would be that easy to cook up,
 since MetroWerks AppleScript interface is pretty crusty.  In any case,
 it would probably share almost no code with the Unix & Windows
 versions...  This may happen someday, but given that the Mac really is
 the poor cousin for now, I am not holding my breath...

 Also note that the build stuff is not the only part of the TEA.  The
 stubs architecture works fine on the Mac.  The Project files for the
 Sample Tcl Extension demonstrate how to link to the stub version of
 Tcl.  Hopefully, once the distribution mechanism part of TEA starts to
 get implemented, we can include Mac distributions in that as well.

 Jim

 > (This is a 2-part posting: first part on debate of TEA on windows,
 > second a concrete question on how to get it to work; feel free to skip
 > the first part ;-)
 >
 > In article <7tslq6$po8$1@srv38.cas.org>,
 >   lvirden@cas.org wrote:
 > >
 > > It seems to me that as long as Windows and MacOS are so limited in
 > scope
 > > that they require one to pay hundreds of dollars for a vendor specific
 > > compiler environment (MicroSoft, codewarrior, whatever) or as an
 > > alternative force the programmer to work in 'Unix mode', then one
 > > might as well a) abandon all hope of cross platform extensions without
 > > pain and b) consider abandoning Windows and MacOS as supported
 > platforms.
 >
 > Well, I'd prefer my simple question of 'how do I use TEA on Windows'
 > not to degenerate into platform wars, especially in a supposedly cross-
 > platform newsgroup.  However I hope the above reasoning wasn't what
 > went on at the TEA summit to lead to the conclusion that cygwin was the
 > windows solution for TEA.
 >
 > Given that at present VC++ is used to compile Tcl on windows, and
 > Codewarrior is used on MacOS, TEA obviously needs to support them
 > (MacOS being the second class citizen at scriptics is obviously largely
 > ignored in this).
 >
 > It seems to me the real need for all that config/autoconf stuff in TEA
 > is because Tcl/extensions need to compile on 10 different versions of
 > Unix which all look different.  On the other hand, Windows is Windows
 > is Windows: even NT, 95, 98 can all compile from the same makefile.
 > The same applies to MacOS.  Hence at the very least config/autoconf etc
 > is overkill, since almost all the information gleaned by such processes
 > will never change, and the information which will change (where
 > is 'tcl.h') may have to be supplied by hand.... (-with-tclinclude)
 >
 > Without hearing any solid arguments for this rather complex, esoteric
 > process, I must say I support the points raised for a Tcl based
 > solution (perhaps with a nice Tk gui to sit on top of it: point and
 > click generation of makefile/xml-project-file/compilation and
 > installation).
 >
 > ----------
 >
 > Anyway, back to the topic and my original question.  My email someone
 > kindly pointed out that the error:
 >
 > checking whether the C compiler (cl  ) works... no
 > > configure: error: installation or configuration problem: C compiler
 > > cannot creat
 >
 > meants that 'cl', the compiler, wasn't on my path in the cygwin
 > shell.   So I fixed that and now run as follows:
 >
 > $ ./configure --with-tclinclude=C:/Progra~1/TclPro/include
 > loading cache ./config.cache
 > checking for gcc... cl
 > checking whether the C compiler (cl  ) works... yes
 > checking whether the C compiler (cl  ) is a cross-compiler... no
 > checking whether we are using GNU C... no
 > checking whether cl accepts -g... no
 > checking for a BSD compatible install... /cygnus/cygwin-b20/H-i586-
 > cygwin32/bin/
 > install -c
 > checking whether make sets ${MAKE}... yes
 > checking for ranlib... ranlib
 > checking for Cygwin environment... no
 > checking for object suffix... obj
 > checking for mingw32 environment... no
 > checking for executable suffix... .exe
 > checking for Tcl public headers... C:/Progra~1/TclPro/include
 > checking for Tcl configuration... configure: warning: Can't find Tcl
 > configuration definitions
 > $
 >
 > Any ideas on that next problem?
 >
 > thanks for any help,
 >
 > Vince.
 >
 >
 > Sent via Deja.com http://www.deja.com/
 > Before you buy.

 --
 ++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
 Jim Ingham                                              jingham@cygnus.com
 Cygnus Solutions Inc.