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