On 12/9/01 4:04 AM, "Rupert Barrow" <rbarrow@...> wrote:
> le 5/12/01 23:41, Jim Ingham =E0 jingham@... a =E9crit=A0:
> <SNIP - symlinking lib and include>
>> I really don't want to have to do this. I don't think it is a good idea=
>> have two paths particularly for linking to Tcl/Tk. If we are going to g=
>> up & build other things using the Unix layout, then we should just bag u=
>> frameworks altogether. Otherwise, it will just be a source of installat=
>> nightmares... It also means that our install will collide with an X11 b=
>> version of Tk. By using Frameworks for the Mac OS X install, we keep th=
>> 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 al=
>> works for Itk - I need another weekend to finish this off. Then I will =
>> 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=
>> 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 !
The symlinking isn't a bad idea, but the *Config.sh is a better one...
>> If you have extensions that use hand-crafted Makefiles, you really shoul=
>> 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=
>> much to get this working.
> I am porting an autoconfig/automake-based opensource software. What is th=
> 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=
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 =
current TIP to clarify this process as well.
> <SNIP - PrivateHeaders>
>> 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=
>> 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=
>> -framework argument. That is how it was intended to work, though I woul=
>> be surprised if this were not all that clearly documented. But even so,=
>> seems an unnecessary complication...
> Good. BTW, should the *Config.sh go into the Headers directory ? It would=
> best to put it directly under the ...Versions/8.4 root. No symlink back t=
> the Tk.framework wrapper root dir, since it is vital to explicitely speci=
> (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.
>>> - 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=
>>> broom ! In Tk's, Jim worked nicely around some *glaring* bugs in Apple'=
>>> "copy files build phase" : well done, I will reuse that.
>> Thanks. The PB folks know about the copy files build phase bugs, this a=
>> 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=
>> to hack into the Tcl Makefile.in more than absolutely necessary. I don'=
>> think it will be to hard to fix this, however.
> It would be nice to design a possibly reusable PB template project along =
> 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=
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 Ingham jingham@...
Developer Tools - gdb