[Xquartz-dev] Re: deprecating xmkmf / imake

Jeremy Huddleston jeremyhu at apple.com
Wed Apr 9 13:19:04 PDT 2008


On Apr 9, 2008, at 00:57, Martin Costabel wrote:
> What would you have to do for that "life support"? Currently, the  
> utils including xmkmf/imake are contained in released X11R7.?.

You are in error here.  The last time xmkmf and imake were in a  
standard release (and not "available" as deprecated software) was with  
X11R6.8 which was first released at the end of 2004 and X11R6.8.2 was  
the last of the series in February 2005.  Over 3 years ago!

There have been 4 releases of X11 since then (X11R7.0, 7.1, 7.2, 7.3),  
and we are on the virge of a fifth.  It's not like X.org deprecated  
this last week and we decided to remove it.  It is included in Leopard  
and isn't being deleted by us.  xmkmf and imake are available for you  
to build and install if you want... or you can just use the ones that  
came with Leopard.

> While they are not used for *building* xorg, they are in the source  
> release, and the binary executables are built if one follows the  
> published rules for building xorg X11.

No, they are not in the normal release.  They are "available" and  
deprecated.

If you don't believe me, here's a quote from the Fedora SRPM:

"""
Imake is a deprecated source code configuration and build system which
has traditionally been supplied by and used to build the X Window System
in X11R6 and previous releases.  As of the X Window System X11R7  
release,
the X Window system has switched to using GNU autotools as the primary
build system, and the Imake system is now deprecated, and should not be
used by new software projects.  Software developers are encouraged to
migrate software to the GNU autotools system.
"""


> The only thing that has to be done specifically for the Mac is to  
> define some lines in a config file or two, but this has to be done  
> only once (not even once, it can be left where it is currently in  
> Leopard's X11.) And it is much easier to do this if everything,  
> including imake, is inside /usr/X11, than if it has to be done by  
> Fink or Macports where imake and the config files are in /opt/local/  
> or /sw/ and the rest of the X11 distribution is in /usr/X11.
>
> Now, of course, if you count 1 engineer-hour of an Apple engineer as  
> the equivalent of 100 volunteer-hours of Fink or xfig developers,  
> you may see this differently...

It's not that simple.  The problem is that xmkmf and imake don't work  
right.  The config file that they pull from is outdated and doesn't  
define things correctly.  I'd be surprised if it even worked to  
correctly build fat binaries for mixed endianness.  The better  
solution is to not waste development hours fixing this archaic build  
system when development hours could be spent modernizing the projects  
to build properly.

Additionally, all of x.org moved to autoconf 3 years ago.  A good  
chunk of the engineering for transitioning these projects has already  
been done.  Furthermore, I have offered (and continue to offer)  
assistance in this transition if you need it.

If anything, I have continually shown willingness to mitigate impacts  
on fink, Macports, etc as I myself have been an open-source developer  
for over a decade now.  I have offered solutions and even included  
"kludges" in Xquartz itself to workaround "issues" in fink while they  
get properly addressed... (how goes the transition to pkg-config in  
fink, btw?  Is there anything still using /usr/bin/X -version and  
checking for the "X.org Release 7.2" string, or can I remove that  
string?)

I think I've fully explained myself and my reasons.  I don't want to  
continue wasting time explaining this over and over when this time  
could be devoted to actually developing software and _fixing_  
applications like xfig to use autoconf rather than imake.

--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/20080409/bd98fb7d/smime-0001.bin


More information about the Xquartz-dev mailing list