Re: [MACTCL] tkConfig.sh

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

Marc-Antoine,

On Friday, October 19, 2001, at 05:27  AM, Marc-Antoine Parent wrote:

>>> Well, I also had to adjust that application to use the #include 
>>> <Tk/tk.h> notation...
>>> Do you think we could push for the include notation to be specified 
>>> in the t_Config.sh-es ?
>>> Actually, the best would be to add a flag saying : This is a (Darwin) 
>>> framework. That flag could then impact both the compilation/linkage 
>>> flags and the import notation. I also see the import of this since 
>>> darwin can accommodate Tcl and Tk as either shared libraries or as 
>>> frameworks; and Tk as either a X11 or Aqua library. Both are valid 
>>> choices to different users, and the configuration files should not 
>>> infer either from the platform alone.
>>> Hence the importance of a 'framework' flag...
>>
>> I am not sure whether is is best to work this into configure or do it 
>> as a post-processing step.  I was planning tenatively to do the 
>> "#include <Tcl.h>" -> "#include <Tcl/Tcl.h>" when  I moved the headers 
>> into the framework, I see no reason to load down the configure for all 
>> the other platforms with this detail, and it would be very easy to do 
>> this as a shell script build phase in PB.  However, I did add a 
>> framework macro to the tcl.m4 in tcl/unix, and use the defines in a 
>> few places in configure.in.  So there is some structure in place on 
>> the tcl build side to do this.  I tend to the PB solution myself, 
>> 'cause I like working in PB.  Again, if some ambitious person wants to 
>> get together the configure/make for Tk, I would at least use the 
>> configure part to generate the tkConfig.sh in my PB project...
>>
>> On Darwin & frameworks...  Wilfredo was moving away from using 
>> Frameworks for all the Darwin stuff.  He thought it was a bad idea to 
>> add all this work to EVERY Unix project.  I don't know what Jordan's 
>> feeling on this is, however.  In my case, the Tcl build will be 
>> different for Mac OS X and Darwin, since I want to build in the 
>> Resource handling stuff, some understanding of aliases, and the 
>> AppleScript and maybe TclAE, and have all this be a standard part of 
>> the Tcl distro...  So I don't think that Darwin & Mac OS X Tcl need to 
>> have the same distribution mechanism.
>
> I agree with you that the Darwin and MacOSX Tcl/Tk are different 
> beasts, and do not need to use the same mechanisms.
> This is precisely why I believe we need to "burden" the unix build 
> mechanisms, such as  TkConfig.sh, with the dylib vs framework 
> distinction. Indeed, the problem goes beyond building the Tcl/Tk 
> frameworks from the command line or ProjectBuilder; all unix clients of 
> the Tcl/Tk code (like Mozart, and Python, and...) need to change, not 
> only their compile and link flags (handled by tkConfig.sh) but also 
> their #include directives to adjust to an (optionally) framework-based 
> Tcl/Tk... We cannot expect all these to use PB. That means that the 
> Tcl/Tk framework must expose its frameworkness to the unix world. This 
> is why I made the half-joke, half daydream that the notion of 
> framework, and what it entails for the build process, will eventually 
> have to make it all the way to autoconf! (I understand why Wilfredo 
> Sanchez was reluctant. But I think that frameworks are a Good Idea in 
> terms of what they allow for linking, and the *n*x community at large 
> can benefit.)

They are nice in general, but they are particularly nice for Tcl & Co.  
Here you often have the problem of keeping together a shared library and 
some Tcl script files, and being able to find both.  The CFBundle API's 
mean that if the linker can find the shared library, you can unerringly 
find the correct script files in the framework.  This leads to a great 
simplification in the work that tcl_findLibrary has to do.

>
> So, formally, my short-term proposal is to add 
> "TK_DARWIN_FRAMEWORK=true" to the tkConfig.sh (idem for tcl, of course) 
> so that we can test for this flag in the mozart codebase, and choose 
> the #include directive accordingly.

I think you misunderstood me.  The question I was debating internally 
was not whether to generate a Framework-ified tkConfig.sh, etc, but 
rather whether to use tcl.m4 and configure.in to generate the 
appropriate entries in the file, or to provide some post-processing in 
the header copy phase on the MacOS X side to fix up these files.  The 
former is a better engineering solution, but a lot more work, and I 
don't think that the benefits outweigh the cost right now - I have a lot 
of other things to work on at the same time.  If someone else wants to 
take this up, though, that would be really great.

I definitely agree that the TEA-style config scripts should be generated 
in such a way as to be useful for the Tcl and Tk frameworks.

Jim

--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer