Re: [MACTCL] Build problems with combined Aqua X11 framework

[Daniel A. S. <st...@ic...>]

Bill,

apologies for the long delay

On 07/06/2005, at 16:38, Bill Northcott wrote:

> Perhaps I am missing something, but the decision to package the X11  
> tk as a version within Tk.framework does not seem right.

this is certainly up for discussion and still an experimental new  
feature of the tk/macosx/Makefile, but I have thought quite a bit  
about this and believe it's actually the correct decision... (it's  
certainly the easiest to implement)

>   I can see no way to have the framework mechanism access anything  
> other than the 'Current' version at build time.

yes, but that's by design, frameworks are supposed to work that way:

you are only supposed to be able to link against the framework  
version that is symlinked as XXX.framework/Versions/Current
OTOH, once built, binaries should not depend on the value of the  
XXX.framework/Versions/Current symlink, everything should link  
through directly to XXX.framework/Versions/8.x

this way you can change the XXX.framework/Versions/Current symlink at  
any time before building to decide which version to link against  
(without affecting any already built binaries)

i.e. to build against tcl 8.5 and tk/auqa 8.5, you'd do

     sudo ln -fsh 8.5 /Library/Frameworks/Tcl.framework/Versions/Current
     sudo ln -fsh 8.5 /Library/Frameworks/Tk.framework/Versions/Current

or for tcl 8.4 and tk/x11 8.4:

     sudo ln -fsh 8.4 /Library/Frameworks/Tcl.framework/Versions/Current
     sudo ln -fsh 8.4-X11 /Library/Frameworks/Tk.framework/Versions/ 
Current

and everything will work like you want (indeed with the same exact  
configure line you can build against either TkAqua or TkX11 or 8.4 or  
8.5, just by changing these two symlinks)

you should also be able to create a Tk.framework replica with  
symlinks to the real Tk.framework of the desired version in a  
separate location and then pass an appropriate -F flag for that  
location to the compiler/linker

> So for R I need flags like:
>
> --with-tcl-config=/Library/Frameworks/Tcl.framework/tclConfig.sh \
> --with-tk-config=/Library/Frameworks/Tk.framework/Versions/8.4-X11/ 
> tkConfig.sh \
> TCLTK_LIBS='-framework Tcl /Library/Frameworks/Tk.framework/ 
> Versions/8.4-X11/Tk' \
> TCLTK_CPPFLAGS='-I/Library/Frameworks/Tcl.Framework/Headers \
> -I/Library/Frameworks/Tk.framework/Versions/8.4-X11/Headers'
>
> this messy and hard to do with autoconf.  Even worse, it is version  
> dependent.

indeed, but that's because you are not supposed to go into the / 
Versions/8.x subdirs of the framework at build time... the framework  
version that is Current gets automatically burned into the binaries  
at link time.

> OTOH if there was a separate framework Tk-X11.framework everything  
> would be much cleaner:
>
> --with-tcl-config=/Library/Frameworks/Tcl.framework/tclConfig.sh \
> --with-tk-config=/Library/Frameworks/Tk-X11.framework/tkConfig.sh \
> TCLTK_LIBS='-framework Tcl -framework Tk-X11' \
> TCLTK_CPPFLAGS='-I/Library/Frameworks/Tcl.Framework/Headers \
> -I/Library/Frameworks/Tk-X11.framework/Headers'
>
> As it stands /Library/Frameworks/Tk.framework/Versions/8.4-X11/ 
> tkConfig.sh is actually incorrect because it gives the flags to  
> link the library as '-framework Tk', which will link the Aqua library.

it is correct if the 'Current' link is changed...

the main reason a Tk-X11.framework is inconvenient is that it is  
harder to build with the existing configure/make unix buildsystem:  
for the 8.4-X11 version approach, all that is needed is a makefile  
override of VERSION, but for a TkX11.framework, we
would need to override the library name at configure time, I don't  
see an easy way of doing that without changing configure.in (adding  
yet another option)...

> Also if there was a Tk-X11.framework, the build would automatically  
> use the latest version while keeping older versions available for  
> runtime time linking which seems to me to be in the spirit of the  
> framework idea.

but that's still possible with the current approach, 8.5-X11 etc  
could be present, and Current changed to whatever is needed at link  
time.

but as mentioned, I'm certainly open to discussion on this...

Cheers,

Daniel

-- 
** Daniel A. Steffen     **  "And now for something completely
** Dept. of Mathematics  **   different"    Monty Python
** Macquarie University  **  <mailto:st...@ma...>
** NSW 2109 Australia    **  <http://www.maths.mq.edu.au/~steffen/>