[Xquartz-dev] Building bundle'able Xquartz

[doh123]

I already do this for Wineskin... it works decently enough

You need a unique location to build XQuartz to, as some of the stuff in it (namely xkb) has to have a hard coded set path, and its not easy to edit after building, so you need to build it yourself.

I suggest building it as installed in /tmp as it works great for me since all users have full read/write to /tmp.  I build WineskinX11 (My slightly modified XQuartz build) as installed to /tmp/Wineskin.  While I fix all my libraries with install_name_tool to run relative to the executable location, for things like xkb, I have it start up by making a symlink at /tmp/Wineskin to the current x11 location inside the app at the time.  It only really needs it for xkb initialization and not later for running, so if that symlink is only important for starting up X, just rm one if there and create a new one on every run... just choose a good name in /tmp that will be unique for sure to build it to run from, not /opt since it would require a password to make a symlink there, and not in /tmp... so non-Admin users can still run the app ok with no special installation.

You can edit XQuartz itself to do certain things at startup when you do your own build to start up certain other programs in X, and then your application would in actuality just be the same as being XQuartz.app named what you want, customized to start up certain things, but with the libraries inside...  I really think this is how XQuartz should always be, but they like it in /opt  :-)

Oh I'd recommend probably editing the source to read the xmodmap from somewhere in through /tmp/whatever too, since by default it only uses ~/.Xmodmap, and you never know what some user might have that messes thing up.

-doh123

On Jun 23, 2011, at 5:47 PM, Tony Bernardin wrote:

> Hi,
> 
> I'm making mac os x application bundle for one of my applications and would like to embed the XQuartz release into it. The reason herefore is that the default X11 on 10.6.x has a flaw that Apple has not been fixing and I would like to follow the typical bundle way where you simply need to drag the bundle onto your Applications folder to run it. My first question is, is can this be reasonably realized? So far I've thought of two approaches:
> 
> 1. Get the XQuartz release, install it, then copy the /opt/X11 content to my My.app/Contents/Libraries/X11 and fix it up. I can modify all the install_names and even edit all the /opt/X11 paths that appear in scripts (e.g., startx), but I don't know what is all just hardcoded into some of the other executables.
> 
> 2. Get the source and build a relocatable XQuartz to embed in the app bundle. I've been trying to follow the instructions here: http://xquartz.macosforge.org/trac/wiki/1.4-apple-git-10.5.5 but when I run autogen.sh for the xorg-macros it complains that I can't use a relative path as --prefix=../Libraries/X11. I'm not sure how the prefix gets used internally, i.e., does it contribute to producing paths that get injected into some of the code at compile time or not.
> 
> I would greatly welcome any advice on creating an embedable X11 release, such that I could run startx from my app bundle's start-up script and have it use only resources that are contained in the app bundle.
> 
> Thanks,
> 
> 
> -- 
> Tony Bernardin,
> Postdoctoral Researcher,
> W.M. Keck Center for Active Visualization in the Earth Sciences (KeckCAVES)
> University of California, Davis
> 
> 
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20110623/17fc4005/attachment.html>