Re: [MACTCL] Bundling Tk on Mac OS X

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

On 12/9/01 4:04 AM, "Rupert Barrow" <rb...@ma...> wrote:

> le 5/12/01 23:41, Jim Ingham =E0 ji...@ap... a =E9crit=A0:
>=20
>>>=20
> <SNIP - symlinking lib and include>
>>>=20
>>=20
>> 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 g=
ive
>> up & build other things using the Unix layout, then we should just bag u=
sing
>> frameworks altogether.  Otherwise, it will just be a source of installat=
ion
>> nightmares...  It also means that our install will collide with an X11 b=
uilt
>> version of Tk.  By using Frameworks for the Mac OS X install, we keep th=
e
>> two versions clearly separated.
>>=20
>> 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 al=
most
>> 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 confi=
dent
>> I can make this work.
>=20
> OK. As a Tck/Tk user, I had never paid much attention to the *Config.sh
> files; now I understand their value. Forget about all the symlinking !

The symlinking isn't a bad idea, but the *Config.sh is a better one...

>=20
>> If you have extensions that use hand-crafted Makefiles, you really shoul=
d
>> 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 th=
at
>> much to get this working.
>=20
> I am porting an autoconfig/automake-based opensource software. What is th=
e
> TEA Makefile style ?

There is a document on the Tcl Resources page (now hosted at activestate)
describing the "Tcl Extension Architecture" and there was also a paper at
year before last's Tcl conference on this.  Basically, it means writing you=
r
makefile to use the defines that the tcl.m4 + *Config.sh set up.  Also, if
you are writing an extension that others might want to link to (like Itcl)
it tells you how to write your own *Config.sh for use with this.  There is =
a
current TIP to clarify this process as well.

>=20
>>>=20
> <SNIP - PrivateHeaders>
>>>=20
>>=20
>>=20
>> 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 framewo=
rk
>> 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 t=
he
>> -framework argument.  That is how it was intended to work, though I woul=
dn't
>> be surprised if this were not all that clearly documented.  But even so,=
 it
>> seems an unnecessary complication...
>=20
> Good. BTW, should the *Config.sh go into the Headers directory ? It would=
 be
> best to put it directly under the ...Versions/8.4 root. No symlink back t=
o
> the Tk.framework wrapper root dir, since it is vital to explicitely speci=
fy
> (my opinion) a Tk version when building something which uses it.

Headers is a symlink to the Headers directory for the current version.  So
you can always pass in Versions/8.4/Headers for --with-tcl if you want to
specify the version.

>=20
> <SNIP>
>=20
>>>=20
>>> - I like the Tcl and Tk ProjectBuilder projects, although they are
>>> different. There is a problem in Tcl's : you cannot 'make clean' with t=
he
>>> broom ! In Tk's, Jim worked nicely around some *glaring* bugs in Apple'=
s
>>> "copy files build phase" : well done, I will reuse that.
>>=20
>> Thanks.  The PB folks know about the copy files build phase bugs, this a=
rea
>> 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 wanti=
ng
>> to hack into the Tcl Makefile.in more than absolutely necessary.  I don'=
t
>> think it will be to hard to fix this, however.
>=20
> It would be nice to design a possibly reusable PB template project along =
the
> lines of what you did for Tcl, to act as a wrapper for configure-based
> opensource stuff ported to MacOSX, including (of course) bundling into
> frameworks and apps. Apple, anyone listening ?

That would be me...  I did one for Classic MacOS, which Bruce Elliott & the=
n
Daniel refined.  I need to bug the PB folks to figure out how to write a
template (it is not that hard) then I can maybe do a quick version of this
which someone else can make better?

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