Re: [MACTCL] Bundling Tk on Mac OS X

[Rupert B. <rb...@ma...>]

le 5/12/01 23:41, Jim Ingham =E0 ji...@ap... a =E9crit=A0:

>>=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 gi=
ve
> up & build other things using the Unix layout, then we should just bag us=
ing
> frameworks altogether.  Otherwise, it will just be a source of installati=
on
> nightmares...  It also means that our install will collide with an X11 bu=
ilt
> version of Tk.  By using Frameworks for the Mac OS X install, we keep the
> 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 alm=
ost
> works for Itk - I need another weekend to finish this off.  Then I will t=
ry
> 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 confid=
ent
> I can make this work.

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 !

> 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 tha=
t
> much to get this working.

I am porting an autoconfig/automake-based opensource software. What is the
TEA Makefile style ?

>>=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 framewor=
k
> 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 th=
e
> -framework argument.  That is how it was intended to work, though I would=
n't
> be surprised if this were not all that clearly documented.  But even so, =
it
> seems an unnecessary complication...

Good. BTW, should the *Config.sh go into the Headers directory ? It would b=
e
best to put it directly under the ...Versions/8.4 root. No symlink back to
the Tk.framework wrapper root dir, since it is vital to explicitely specify
(my opinion) a Tk version when building something which uses it.

<SNIP>

>>=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 th=
e
>> 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 ar=
ea
> 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 wantin=
g
> to hack into the Tcl Makefile.in more than absolutely necessary.  I don't
> think it will be to hard to fix this, however.

It would be nice to design a possibly reusable PB template project along th=
e
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 ?

Rupert