X11 in Macports
Anders F Björklund
afb at macports.org
Sun Nov 23 03:36:27 PST 2008
Jeremy Huddleston wrote:
> 1) The dependency issue
>
> X11 lives in a grey area in Macports' dependency policy. X11 is
> actually given as the example for something that is appropriate to
> use the lib:* or bin:* dependency rather than a port:* dependency,
> yet there are plenty of ports that are still using a port:
> dependency. I believe this is mainly for things like libXrender
> (rather than libX11) as a legacy of what was available in Tiger's
> X11. I'd very much like to use anything in /usr/X11/* over
> installing a duplicate in /opt/local, and I'm sure others are in
> the same boat. I have seen a fair share of bug reports on xquartz-
> dev that came about simply because the macports version didn't have
> a fix that was in the system version or macports config files (eg:
> for fontconfig) didn't match system configurations, so users were
> wondering why some fonts weren't available in some programs.
I think the defacto recommendation is to install Xcode and X11+SDK,
rather than using the various gcc and xorg ports... But like you say,
this is a grey area and so it uses a lot of "both".
But this isn't something that is typical of X11, the same "issue"
appears in a lot of places in MacPorts whether it is about OpenSSL/
libz/libbz2 or if it's about Perl/Python/Ruby...
> 2) The other dependency issue
>
> Now, for what port to actually depend on... Quickly grepping though
> the code, I have seen the following dependencies for libX11:
>
> lib:libX11.6:XFree86
> lib:libX11.6:xorg
> lib:libX11:XFree86
> lib:libX11:xorg
> lib:libX11:xorg-libX11
>
> I'd like to standardize this to be xorg-libX11
Supposedly the "standard" used to be lib:libX11.6:XFree86 which
was meant to be supplied through /usr/X11/lib/libX11.6.dylib
on Leopard and from /usr/X11R6/lib/libX11.6.dylib on Tiger.
(i.e. nobody installed should need the "XFree86" port anyway)
> 3) The old monolith xorg and XFree86
>
> I'd like to eventually punt these in favor of having just one X11
> solution in Macports based on the latest release.
You might want to move some of this functionality into "base".
So that ports could simply say something like "use_x11 yes" ?
I would also like to see something that would loook better than:
platform macosx {}
if { [variant_isset macosx] && ![variant_isset x11] }
{ default_variants +aqua }
if { [variant_isset puredarwin] } { default_variants +x11 }
if { [variant_isset freebsd] } { default_variants +x11 }
That some ports currently have to use to allow both +x11 and +aqua.
There's also the +no_x11 and +quartz variants, muddying up further.
So it seems like it needs something better than Portfile workarounds ?
--anders
More information about the macports-dev
mailing list