Re: [MACTCL] tkConfig.sh

[Marc-Antoine P. <map...@ac...>]

>> 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.)

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.

Enjoy!

Marc-Antoine Parent