Re: [MACTCL] Bundling Tk on Mac OS X

[Jim I. <ji...@ap...>]

Rupert,


Jim



> Hi,
> 
> With Apple's help, Jim has done a great job of bundling Tk on MacOSX in the
> form of a TK.framework. I would like to add the following requirements (for
> Tcl and Tk), which seem to span across several other frameworks on MacOSX
> (e.g. OpenGL et al., i.e. GL, AGL, GLUT, ...)  :
> 
> - in Tk.framework/Versions/<M>.<m>, I would like to :
>   ln -s . lib
>   ln -s Headers include
>   ln -s Tk libtk.dylib
>   ln -s Tk libtk.<M>.<m>.dylib
> (BTW, I always use the precise version number in my -F link option, never
> the 'Current' default : e.g. -F ...Tk.framework/Versions/8.4, not -F
> ...Tk.framework)
> 
> - in Tk.framework, we might like to add the same thing, for those who link
> against the 'Current' version :
>   ln -s . lib
>   ln -s Headers include
>   ln -s Tk libtk.dylib
>   ln -s Tk libtk.<M>.<m>.dylib
> 

I really don't want to have to do this.  I don't think it is a good idea to
have two paths particularly for linking to Tcl/Tk.  If we are going to give
up & build other things using the Unix layout, then we should just bag using
frameworks altogether.  Otherwise, it will just be a source of installation
nightmares...  It also means that our install will collide with an X11 built
version of Tk.  By using Frameworks for the Mac OS X install, we keep the
two versions clearly separated.

However, it should be possible to fix up the tclConfig.sh and generate a
tkConfig.sh such that other builds that use these (which is most Tcl/Tk
extensions these days) can find what they need just using the defines in
there.  I have a tclConfig.sh that works for Itcl, and my tkConfig.sh almost
works for Itk - I need another weekend to finish this off.  Then I will try
some other extensions to make sure I haven't missed anything.  But the
tcl.m4 & friends provide enough of an abstraction that I am pretty confident
I can make this work.

If you have extensions that use hand-crafted Makefiles, you really should
consider moving over to the TEA Makefile style for more general reasons.
But even if you don't want to do this, you still don't have to change that
much to get this working.


> - in Tk.framework/Versions/<M>.<m>/Headers, to make the framework usable, I
> have had to symlink in all the contents of PrivateHeaders :
>   for i in ../PrivateHeaders; do ln -s $i; done
> I think this 'PrivateHeaders' business is pretty useless, and the Apple
> documentation is not clear on what should go in there. So either symlink as
> I have, or put everything in Headers (I prefer the symlink solution, because
> it clearly shows which headers are the public interface).
>


I do agree that the PrivateHeaders thingie is silly, and I will move all
those headers just into Headers.  There is a way to say that one framework
is a "friend" of another and then gcc will include its PrivateHeaders as
well as its Headers on the implicit header search path it derives from the
-framework argument.  That is how it was intended to work, though I wouldn't
be surprised if this were not all that clearly documented.  But even so, it
seems an unnecessary complication...
 
> All this symlink-ing makes it easier to configure&build other stuff which
> uses Tcl or Tk without having to think too much.
> BTW [OT], it would be nice to be able to use something like the
> "--enable-framework" configure option to tell this thing's libtool to link
> to (for example) the Tk framework and not the Tk *.dylib, and generate a
>   -F...Tk.framework/Versions/8.4 Tk
> link option instead of
>   -L...Tk.framework/lib -ltk8.4

The --enable-framework should be recorded when you build Tcl/Tk, and then
the other extensions should just pull the "how to link with Tcl" define out
of the tclConfig.sh, and they would automatically do the right thing.  I
think this is much cleaner than all this cross-linking.  The
--enable-framework can also be used in other extensions to modify their
*Config.sh files to generate Framework linking to their libraries, if you
decide to wrap their Makefiles in a Framework builder as I did for Tcl.

> 
> - I like the Tcl and Tk ProjectBuilder projects, although they are
> different. There is a problem in Tcl's : you cannot 'make clean' with the
> broom ! In Tk's, Jim worked nicely around some *glaring* bugs in Apple's
> "copy files build phase" : well done, I will reuse that.

Thanks.  The PB folks know about the copy files build phase bugs, this area
is undergoing some architectural renovation, and a lot of it should be
cleaner when this is done.  The make clean problem was just me not wanting
to hack into the Tcl Makefile.in more than absolutely necessary.  I don't
think it will be to hard to fix this, however.

Jim
-- 
+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==
Jim Ingham                              ji...@ap...
Developer Tools - gdb