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@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
On Tue, 2008-09-16 at 11:24 -0700, Jeremy Huddleston wrote:
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).
[ ... ]
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).
My apologies if this is redundant info, but .la files are utterly useless on any "modern" *nix system. They fill a hole on some systems where the dynamic linker cannot do what a dynamic/runtime linker should. The OS X, Unix and even the Windows ones are adequately capable, and .la files serve absolutely no purpose on these platforms. They are also an impediment to debugging and other issues. To be honest, I can't even remember which systems needed .la files, but it mostly old SysV-derived commercial unix systems IIRC. Nobody should be using them (or, frankly, (g)libtool, although it does provide a useful veneer over the shared library building process that really should have been replaced by another tool IMHO. Certainly, there are many people using scons now which has the same level of portability for major OS platforms and without any .la nonsense). --p
Paul Davis wrote:
My apologies if this is redundant info, but .la files are utterly useless on any "modern" *nix system. They fill a hole on some systems where the dynamic linker cannot do what a dynamic/runtime linker should.
.la files are used by libtool to create input to the static linker, but are only really useful for creating static libraries/executables. Libtool adds extra, unneeded libraries to the link line when creating dynamic libraries/executables, in many cases causing problems (and forcing the use of, e.g. GNU ld's --as-needed flag). They (.la files) are also used by libltdl when loading libraries with lt_dlopen, but the only system I have come across where the information is useful to libltdl is Tru64 4.0D. Other dynamic linkers load dependent libraries in the correct order, from the correct rpath, as expected.
The OS X, Unix and even the Windows ones are adequately capable, and .la files serve absolutely no purpose on these platforms. They are also an impediment to debugging and other issues. To be honest, I can't even
Many systems do not install .la files, it was, I think, agreed earlier, that Mac OS X 10.6 would be one of them (at least for the X11 bits).
remember which systems needed .la files, but it mostly old SysV-derived commercial unix systems IIRC. Nobody should be using them (or, frankly, (g)libtool, although it does provide a useful veneer over the shared library building process that really should have been replaced by another tool IMHO. Certainly, there are many people using scons now
You had me mostly agreeing with you until you mentioned scons. Scons is one of the worst tools I have ever come across from the point of view of the user attempting to build software.
which has the same level of portability for major OS platforms and without any .la nonsense).
Although some of the Mac OS X bits are built with xcodebuild, the vast majority of the Xorg code is built with the autotools, that is not likely to change this year. Peter -- Peter O'Gorman http://pogma.com
On Tue, 2008-09-16 at 15:02 -0500, Peter O'Gorman wrote:
remember which systems needed .la files, but it mostly old SysV-derived commercial unix systems IIRC. Nobody should be using them (or, frankly, (g)libtool, although it does provide a useful veneer over the shared library building process that really should have been replaced by another tool IMHO. Certainly, there are many people using scons now
You had me mostly agreeing with you until you mentioned scons. Scons is one of the worst tools I have ever come across from the point of view of the user attempting to build software.
My point was merely that its possible to do portable, cross-platform shared library building without creating extra files like the .la's that libtool spews out, and without hiding things in .libs until they are installed. Which clearly makes my post even more off-topic than usual, since the Xquartz project is about as cross-platform as ... well, it simply isn't :) --p
participants (3)
-
Jeremy Huddleston
-
Paul Davis
-
Peter O'Gorman