Comments on switching to the Cygnus development system

0 views
Skip to first unread message

Tom Hutto

unread,
Apr 27, 1999, 3:00:00 AM4/27/99
to
Brent tells me that Scriptics is considering switching compilers. They
intend to migrate from VC++ to the Cygnus tool set available at
http://www.cygnus.com,

The best part is that it's not Microsoft and it's free. The bad part is
that 1)it's a UNIX/POSIX like environment, 2) several non-POSIX hacks are
present, 3)documentation is sparse to non-existent -- they have no 'man'
capability and no 'info' capability so how the heck can we read their
published man pages?

I think the only solution to the development system problem is to start
writing specifications explaining how to build TCL/TK in sufficient detail
that competent programmer can write a makefile for any compiler/linker
combo.

Paul Duffin

unread,
Apr 27, 1999, 3:00:00 AM4/27/99
to

One of the many things that I have sitting in the background is a cross
platform development environment which I call Babel. It provides a
common interface to compilers and linkers and when combined with
something like Bras (a Tcl make) becomes a very powerful combination.

I actually use it myself to build all of my extensions and I find it
very easy to use.

--
Paul Duffin
DT/6000 Development Email: pdu...@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880 International: +44 1962-816880

Alexandre Ferrieux

unread,
Apr 27, 1999, 3:00:00 AM4/27/99
to
Tom Hutto wrote:
>
> Brent tells me that Scriptics is considering switching compilers. They
> intend to migrate from VC++ to the Cygnus tool set available at
> http://www.cygnus.com,

Wow !!! Is that true ?
Brent, why didn't you tell me ? I thought I had only wasted time on thi
sissue, and apparently it's quite the converse...

> The best part is that it's not Microsoft and it's free. The bad part is
> that 1)it's a UNIX/POSIX like environment, 2) several non-POSIX hacks are
> present, 3)documentation is sparse to non-existent -- they have no 'man'
> capability and no 'info' capability so how the heck can we read their
> published man pages?

Brent again, correct me if I'm wrong, but the key is the *library*, not
the compiler !
Cygnus brings a true POSIX layer, which allows to crap all that messy
Win32-based pseudo-compat code developed over the years. And this
specific POSIX library has been tested in many more cases than the code
in the win/ subdirectory of Tcl distribs, which by definition has only
been tested in its current Tcl use !

> I think the only solution to the development system problem is to start
> writing specifications explaining how to build TCL/TK in sufficient detail
> that competent programmer can write a makefile for any compiler/linker
> combo.

Ah-ha. The question of the OS API doesn't seem to be much of a problem
for you. Interesting :)

-Alex

Scott Redman

unread,
Apr 27, 1999, 3:00:00 AM4/27/99
to

Tom Hutto wrote:
>
> Brent tells me that Scriptics is considering switching compilers. They
> intend to migrate from VC++ to the Cygnus tool set available at
> http://www.cygnus.com,

Actually, the first plan is to use the Cygnus tools for configure,
make, and the binutils. The compiler is another story altogether.
I think there was some miscommunication... However, switching
to a configure-make model on Windows will help in allowing support
for GCC. We can't go 100% GCC in the forseeable future, due
to library and compatibility constraints.

> The best part is that it's not Microsoft and it's free. The bad part is
> that 1)it's a UNIX/POSIX like environment, 2) several non-POSIX hacks are
> present, 3)documentation is sparse to non-existent -- they have no 'man'
> capability and no 'info' capability so how the heck can we read their
> published man pages?
>

> I think the only solution to the development system problem is to start
> writing specifications explaining how to build TCL/TK in sufficient detail
> that competent programmer can write a makefile for any compiler/linker
> combo.

I think we all agree about this last statement.

-- Scott

Scott Redman

unread,
Apr 27, 1999, 3:00:00 AM4/27/99
to
See my reply to Tom's message...

> Wow !!! Is that true ?
> Brent, why didn't you tell me ? I thought I had only wasted time on thi
> sissue, and apparently it's quite the converse...
>

> > The best part is that it's not Microsoft and it's free. The bad part is
> > that 1)it's a UNIX/POSIX like environment, 2) several non-POSIX hacks are
> > present, 3)documentation is sparse to non-existent -- they have no 'man'
> > capability and no 'info' capability so how the heck can we read their
> > published man pages?
>

> Brent again, correct me if I'm wrong, but the key is the *library*, not
> the compiler !
> Cygnus brings a true POSIX layer, which allows to crap all that messy
> Win32-based pseudo-compat code developed over the years. And this
> specific POSIX library has been tested in many more cases than the code
> in the win/ subdirectory of Tcl distribs, which by definition has only
> been tested in its current Tcl use !

It is the library issue...but there are some concerns about using
GCC with the MSVC++ runtime as well. The POSIX layer may not provide
everything needed to get rid of the Win32 "stuff", especially since
there are users that won't be able to use the cygwin library. But,
we really don't want to restrict everyone to VC++...once the make &
configure stuff is done, we can entertain thoughts of supporting
other compilers (like GCC or Borland).



> > I think the only solution to the development system problem is to start
> > writing specifications explaining how to build TCL/TK in sufficient detail
> > that competent programmer can write a makefile for any compiler/linker
> > combo.
>

> Ah-ha. The question of the OS API doesn't seem to be much of a problem
> for you. Interesting :)

The POSIX-like layer of cygwin will mean some "re-porting" work. I think
that Cygnus has already done most of this work, and you can get a copy
of Tcl/Tk from them, already built with cygwin (at least, I think that's the
case).

-- Scott

Jean-Claude Wippler

unread,
Apr 27, 1999, 3:00:00 AM4/27/99
to
Scott,

> Tom Hutto wrote:
[...]

> > I think the only solution to the development system problem is to
> > start writing specifications explaining how to build TCL/TK in
> > sufficient detail that competent programmer can write a makefile for
> > any compiler/linker combo.
>
> I think we all agree about this last statement.

And now that we have this stub mechanism, perhaps also consider writing
instructions to build things *without* having Tcl/Tk installed, or with
an entirely different version. It may sound strange, but I run into
such things - either no Tcl installation present, or the wrong one.

-- JC

James Ingham

unread,
Apr 27, 1999, 3:00:00 AM4/27/99
to
Scott,

>
> The POSIX-like layer of cygwin will mean some "re-porting" work. I think
> that Cygnus has already done most of this work, and you can get a copy
> of Tcl/Tk from them, already built with cygwin (at least, I think that's the
> case).
>

No, we have not done this porting work for Tcl. The version of Tcl
that we have built with Cygwin uses the "win" directory. We have
not changed the Makefiles around to use the unix subdirectory of Tcl.

We do build Expect on top of the Cygwin DLL, but not the base Tcl/Tk
distribution.

This is mostly due to inertia, and the fact that GDBTk, which is my
main use for Tk here, does all its socket & serial handling in gdb
code, which DOES go through the Cygwin DLL, so we don't much use the
contentious parts of Tcl on Windows...

Jim

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

Mumit Khan

unread,
Apr 28, 1999, 3:00:00 AM4/28/99
to
In article <mfzp3tv...@leda.cygnus.com>,

James Ingham <jin...@cygnus.com> wrote:
>
>No, we have not done this porting work for Tcl. The version of Tcl
>that we have built with Cygwin uses the "win" directory. We have
>not changed the Makefiles around to use the unix subdirectory of Tcl.
>
>We do build Expect on top of the Cygwin DLL, but not the base Tcl/Tk
>distribution.

Here're some of the issues I see. Please comment.

1. Use Cygwin tools to build Tcl/Tk as a Unix/X11 platform. Currently all
it takes is to do the following:

$ ./configure
$ make CFLAGS="-g -O -U_WIN32 -UWIN32 -UWINNT"

however it tickles a few trivial bugs in the Cygwin header files, and
the fixes are already in the Cygwin development branch. Contact me if
you need more info.

You obviously need Cygwin X11 dev environment installed. This is
obviously not for everyone, but it's nice to be able to test and
debug my applications from my Unix box, and then rebuild using win32
API.

2. Use Cygwin tools to build Win32/Cygwin platform. This, as Jim points
out, uses win directory. This also has quite a few "weird" tricks in
it:
- the environment needs to be sync'd correctly. This is currently
done by redefining putenv to a Cygwin specific code.

- pathnames need to be translated correctly to win32 for handing
off to win32 API and then back for user. Currently this code
is buggy, but works for most "normal" uses. I overhauled the
current code at one point, and will get it out of the CVS repo
sometime soon.

3. Use Cygwin development tools, but build with Mingw compiler. Mingw
compiler can use either CRTDLL (comes with all win32 machines) or
MSVCRT (which is what MSVC uses, and comes with most newer machines
or machines that have MSVC/Explorer/etc installed). This is the
so-called "-mno-cygwin" mode.

Pros:
- Native win32, no licensing/copyright issues.
- just a few minor patches, mostly to work around msvc-specific coding
in tcl/tk. It took me an hour to get tcl/tk8.1b3 to build correctly.
Most of the time was to convert the makefile.vc to a Unix'y makefile
format.

Cons:
- Contrary to popular belief, you need a few extra things on top of
Cygwin dev tools to work in -mno-cygwin mode. For more information
on how to get mno-cygwin work correctly, see my MNO-CYGWIN HOWTO
http://www.xraylith.wisc.edu/~khan/software/gnu-win32/. This is
quite trivial however, so it shouldn't be a burden.

- The current set of win32 API headers won't work without some patches.
We're moving to Anders Norlander's w32api package, and I needed to
add just a few minor patches to 0.1.5 release. Next release either
from Anders or packaged with my distribution will have this solved.

4. Use Mingw compiler and some port of make. Most mingw ports of make,
including mine, is full of bugs and I don't have the motivation to
fix it. Mostly shell (or lack thereof) issues. You can conceivably
use "dmake", which is what Perl folks do.

5. A big bonus is that I build everything on a Unix host and then just
copy it over. Life's a lot more pleasant this way ...

Personally, I'd like to see a free compiler "supported" even if Scriptics
does the development and testing using a native compiler (aka MSVC ;-).

Regards,
Mumit


Alexandre Ferrieux

unread,
Apr 28, 1999, 3:00:00 AM4/28/99
to
James Ingham wrote:
>
> Scott,
>
> >
> > The POSIX-like layer of cygwin will mean some "re-porting" work. I think
> > that Cygnus has already done most of this work, and you can get a copy
> > of Tcl/Tk from them, already built with cygwin (at least, I think that's the
> > case).
> >
>
> No, we have not done this porting work for Tcl. The version of Tcl
> that we have built with Cygwin uses the "win" directory. We have
> not changed the Makefiles around to use the unix subdirectory of Tcl.
>
> We do build Expect on top of the Cygwin DLL, but not the base Tcl/Tk
> distribution.
>
> This is mostly due to inertia, and the fact that GDBTk, which is my
> main use for Tk here, does all its socket & serial handling in gdb
> code, which DOES go through the Cygwin DLL, so we don't much use the
> contentious parts of Tcl on Windows...

No problem; whenever you do that "win-less" port, please drop me a line
! I lack the time to dig into all the licensing/-nocygwin issues, but I
could use a binary...

Thanks in advance,

-Alex

Tom Hutto

unread,
Apr 28, 1999, 3:00:00 AM4/28/99
to
My apologies to Brent for starting a furball by putting words in his mouth.

My thanks to all who contributed to this thread. I've saved it for later
use.

My thanks to Alex for pointing out that I ASS-U-MEd that the phrase
"compiler/linker combo" included the concept of also supporting
OS/LIBS/HARDWARE/yadda-yadda-yadda. And, he's correct when I assumed that
the libs, etc. are not a problem -- there is a history. I hope that I don't
assume myself into a hole.

Scott Redman <red...@scriptics.com> wrote in message
news:3725E625...@scriptics.com...


>
> Tom Hutto wrote:
> >
> > Brent tells me that Scriptics is considering switching compilers. They
> > intend to migrate from VC++ to the Cygnus tool set available at
> > http://www.cygnus.com,
>
> Actually, the first plan is to use the Cygnus tools for configure,
> make, and the binutils. The compiler is another story altogether.
> I think there was some miscommunication... However, switching
> to a configure-make model on Windows will help in allowing support
> for GCC. We can't go 100% GCC in the forseeable future, due
> to library and compatibility constraints.
>

> > The best part is that it's not Microsoft and it's free. The bad part is
> > that 1)it's a UNIX/POSIX like environment, 2) several non-POSIX hacks
are
> > present, 3)documentation is sparse to non-existent -- they have no 'man'
> > capability and no 'info' capability so how the heck can we read their
> > published man pages?
> >

> > I think the only solution to the development system problem is to start
> > writing specifications explaining how to build TCL/TK in sufficient
detail
> > that competent programmer can write a makefile for any compiler/linker
> > combo.
>
> I think we all agree about this last statement.
>

> -- Scott

Reply all
Reply to author
Forward
0 new messages