This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] Updated: expect-20021218-1, gdb-20021218-1, tcltk-20021218-1


Christopher Faylor wrote:
How have you managed to build cygwin in the past?  The rationale for the
name difference has been made clear before.  It is to make it clear that
these libraries are for modified cygwin versions of tcl/tk.  I'm not
really willing to arbitrarily change the convention now.
But right now, there is no other version of tcl/tk available at all. Nobody is trying to link against an X-based tcl/tk. [there was a discussion about this a year ago, but nothing ever came of it] We're talking about your non-X build. To actually compile an application that uses *your* tk, one must *still* have the Xish tk headers available somewhere.

But not in /usr/X11R6/include or /usr/include/X11/ because those are for *real* X headers. Hence, /usr/include/tk/X11/.

However, if someone wants to submit a patch to the insight mailing list
that would be the appropriate way to deal with this.
It's not an insight issue, it's a "I want to build ANYTHING that uses cgf's tk". so, you might ask, why do insight and gdb build properly? See below...

Also, I don't have any intentions of changing anything in tcl/tk
packaging to try to accommodate a non-cygwin-released X11 version of
tcl/tk.
Err...I don't know what you're getting at here -- we're not talking about accomodating ANY other version of tcl/tk. We're just talking about adding the files that are needed to make YOUR version of tcl/tk usable for development. Even the non-X version of tk assumes that certain Xish tk headers will be available. From what I can tell, it #defines a few things to make these calls no-ops or to redirect them to the appropriate win32-centric routines -- but it still unconditionally #includes some of the X11/tk*.h files.

The thing is, if you build gdb as part of the uberbaum source tree(*), you never notice -- because gdb just reaches over into the tk/ source directories to find those headers. But, if you're trying to build something ELSE -- like python's tcl module -- and DON'T have the uberbaum source tree, you're out of luck because the Xish tk files are not in the cygwin tk dist. **even though you're building a pure win32 non-X** program.

(*) or something close to it, like /cygnus/netrel/build/ which contains the gdb source tree, and the tcl/tk source tree, and and and ... so that insight/gdb configury can reasonably guess where to "reach" for the tk-Xish headers.

This is especially true since, AFAICT, moving tk header files
into /usr/include/tk would mean changing every package that tried to
use tcltk.
Well, they have to go somewhere -- and putting them into /usr/X11R6/include/X11 or /usr/include/X11 is bad bad bad.

At least this way, you can simply say "CFLAGS=-I/usr/include/tk" if necessary, and voila' -- it's possible to build a non-X but cgf-tk-linked program.

I guess, it is obvious that I'm really not extremely interested in new
packaging ideas for tcltk. I'm releasing it so that insight and expect
can use it.
But they can't, as is. Try to build insight or expect on a machine that simply has your binary tcl/tk dist installed, but doesn't have the tcl/tk source tree.

Can't be done -- unless you ship the include files as described above.

If someone else wants to take over packaging and go nuts
making it work with other packages, I'll happily hand over
mantainership.
Your dist is *broken* for any development -- although it works for end users who don't compile anything that uses tk. It only works for your development -- e.g. building insight -- because you *also* have uberbaum (ne' /cygnus/netrel/build/ as described above). And you build insight/expect in the uberbaum tree (or /cygnus/netrel/build...)

Now, I dunno about the symlinks for the import libs. They WERE necessary in the bad old days, because tclConfig.sh and tkConfig.sh were hopelessly screwed up. But now, tclConfig.sh and tkConfig.sh look mostly right -- maybe even completely right -- and they point at the libcyg* import libs. So, those links might be unnecssary.

Besides, end-users can always make symlinks if they need 'em. But they can't whistle up the missing Xish tk includes unless they come with the tcltk package.

I appreciate the work you have done in getting tcl/tk 8.3 to compile on cygwin; it was a massive effort that defeated me the one time I tried it, and drove the other insight developers to distraction. So kudos to you.

but....

your effort was narrowly focused: you needed insight to work. Period, end of story. And you reached that goal, and that's good. But in the process, we have a tcl/tk that is useful only for runtime usage by other packages that you compile on your machine. I can't compile anything on my machine without scrounging additional files out of your src dist that are missing from your binary dist.

So pretty please, add the Xish headers to your binary dist?

--Chuck


--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]