Re: [MACTCL] Xcode native targets (Was: ATSU patch)

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

Daniel,

On Feb 23, 2004, at 5:44 AM, Daniel A. Steffen wrote:

> James,
>
> On Friday, Feb 20, 2004, at 07:38 Australia/Sydney, James Tittle II 
> wrote:
>
>> ...to this, I'm building now within XCode, but haven't made a 
>> successful "native" target...hopefully that can get sorted soon ;-)
>
> I've looked into this, and I don't think we can move to native targets 
> easily, mainly because we use the (deprecated) GLOBAL_CFLAGS 
> containing a shell backquote to extract relevant C flags from 
> tclConfig.sh directly.
> This doesn't work in XCode native targets because the build process 
> doesn't go through the shell anymore to execute the compiler (and 
> insists on quoting GLOBAL_CFLAGS, which should be unquoted by 
> definition). There may be a way around this, but I don't think so; 
> Jim?

I tried this a while back and ran into the same problem that you 
mention.  I bugged the Xcode folks, but forgot to report back here.  
Sorry about that...

Anyway, when I ran into this I went to the two build system guys and 
asked them, and after they got over retching a bit, we tried but could 
not think of a way to get a shell script to produce a value for a build 
setting with the Native build system.  I filed a bug asking for that, 
and they agreed that provided there was a straight-forward, declarative 
way to do it, it would indeed be a good idea.  However,  they have lots 
to do, and this is kind of a corner case.  So I have no idea when they 
will get around to it.

>
> We could hardcode the value of GLOBAL_CFLAGS (or in that case rather 
> OTHER_CFLAGS) instead of retrieving it dynamically, but then we would 
> need to keep the tk project and the tcl unix configure scripts in 
> sync, which would be a pain, and might not be valid across MacOSX 
> version changes anyway (e.g. TCL_DEFS is different for tcl built on 
> panther and tcl built on jaguar).
>
> Another reason to wait with native targets is that we need to preserve 
> compatibility with building on 10.2 at least for now. We could have 
> two separate projects (.pbproj and .xcode) but that would double the 
> maintenance effort, not sure if it's worth it.
>

I think it is fine to stay with a Jam based target for now.  The native 
targets have some nice features, but none crucial for us.  Tk isn't all 
that big, so the time to load up the Jam rules before build is not a 
big deal.  We can't make good use of ZeroLink, since that only works 
for Executables and almost all the code in Wish is in the shared 
libraries.  I don't really find Fix & Continue all that compelling.

> In any case, for debugging with native targets, it's easy enough to 
> create your own .xcode project by copying Wish.pbproj as Wish.xcode 
> and upgrading all targets. Then paste the current values of TCL_DEFS 
> and TCL_EXTRA_CFLAGS into GLOBAL_CFLAGS. I have a current such .xcode 
> project if people are interested.
> However, to be able to fix&continue, I looks like you also need to 
> move all the Wish library code into the Wish executable (i.e. no 
> framework), otherwise it seems impossible to fix code in Tk library 
> code?

You can do Fix & Continue in shared libraries.  Just not ZeroLink.

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