[Xquartz-dev] Notes on OSX 10.5.5

[Jeremy Huddleston]

Moved to xquartz-dev 'cause that's more appropriate for this discussion.

On Sep 16, 2008, at 08:39, Mike Meyer wrote:

> On Tue, 16 Sep 2008 00:51:11 -0700
> "Jordan K. Hubbard" <jkh at apple.com> wrote:
>> fingers).  If, even so, someone can still come up with a compelling
>> argument for making "the user bits" and "the developer bits" one  
>> piece
>> again, I'm certainly willing to listen to it.
>
> Two reasons:
>
> 1) If they're one package, they're never out of sync with each other.

I believe the reason for the split initially was to decrease file  
size.  X11 is actually split into 3 packages, X11User, X11SDK, and  
X11Doc.  IIRC, X11SDK and X11DOC combined are less than 1M, but I  
don't recall exactly.

That seems absurd to me, to me given the headache this is causing now,  
but it made more sense back with Tiger's X11 which was based off of  
XFree86 and had a much more stable SDK and didn't use autoconf/libtool  
(hence no .las).

Furthermore, the goal is that we need to have a stable API that one  
can build off of and distribute an application to any 10.5.x system,  
so the API itself (which is what the SDK package is supposed to be) is  
not supposed to change.  X11 in OSX has pushed the threshold of that  
position over the past few updates in order to jump forward as much as  
possible in the "official" updates to bring the progress you've seen  
here in the community to the users at large.  The extent to which that  
threshold has been pushed coupled with the disjoint between the X11SDK  
and X11User updates has made that less than smooth for the power user  
and developer, but that is where xquartz.macosforge.org comes in for  
now.  Hopefully with 10.6, these issues will be irrelevant.  We've  
learned from these mistakes, and changes have been put in place to  
make sure they don't happen in the future.  I wish I could turn back  
the clock and address this in Leopard, but I really don't see how  
that's possible with the disconnect between these two packages.  The  
best thing we can do is just remove the .la files from future Xcode  
releases (which will make "fresh" systems work, but will leave  
reference issues in existing macports/fink installs... which are  
"broken" already).

> 2) As part a larger ecosystem, having applications split into user and
>  developer packages makes things very painful for the developer.

Yeah.

>  Details upon request. I don't know if that's where things are
>  going, but even if not, it would be nice if installing the user
>  bits included an option to install the developer bits, and even
>  better if there were a user-settable global default. (sorry if
>  that's already happened).

This is an interesting idea, but it's far over my head.  As a  
developer (putting on my open-source hat and taking off my Apple hat),  
I'd love to see SDK updates coupled with OS updates rather than  
downloading new XCode releases for that.  I like the idea that Xcode  
is *just* an application and not some monolithic conglomeration of  
every SDK on the system on top of all that.

Certainly, lay out what you think would be appropriate and try to  
anticipate retorts against it... at worst, it'll spark some discussion  
here and get people thinking more about this problem.

--Jeremy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3221 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20080916/ef60fb58/attachment.bin