Mail Archives: cygwin/2002/12/30/19:01:42
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/
- Raw text -