Re: XDarwin.app is installed with symlinks inside MainMenu.nib bundles, app won't launch.

On Sun, 22 Apr 2007 10:29:12 -0600, Marc Aurele La France wrote:

> On Tue, 17 Apr 2007, Marc Aurele La France wrote:
>> On Sun, 15 Apr 2007, Yves de Champlain wrote:
>>> Le 07-04-15 à 14:55, Marc Aurele La France a écrit :
>>>> On Wed, 11 Apr 2007, SciFi wrote:
>>>>> 6.  XDarwin.app is installed with symlinks inside MainMenu.nib
>>>>> bundles, app won't launch.
> 
>>>>> Discussion:
> 
>>>>> The make-install process is creating/copying symlinks for the
>>>>> innards of the MainMenu.nib bundles instead of copying the actual
>>>>> files.  This is for each language inside the installed XDarwin.app
>>>>> bundle itself.
> 
>>>>> As installed, we'll see errors in console.log concerning the
>>>>> language couldn't be loaded, and the app will fail to launch.
> 
>>>>> This is what we _should_ see in the installed app-bundle after
>>>>> repaired by hand:
>>>>> $ cd /Applications/XDarwin.app/Contents/Resources/English.lproj/
>>>>> MainMenu.nib
>>>>> $ ls -alL
>>>>> total 28
>>>>> drwxr-xr-x 5 scifi wheel   170 2007-04-04 11:05 . dr-xr-xr-x 7 root 
>>>>> wheel   238 2007-04-11 02:26 .. -rw-r--r-- 1 scifi wheel  2369
>>>>> 2003-10-16 18:50 classes.nib -rw-r--r-- 1 scifi wheel 20640
>>>>> 2003-10-16 18:50 objects.nib
> 
>>>>> The xf86 installer is creating those two .nib files as symlinks to
>>>>> somewhere in the build/ tree, which further are symlinks elsewhere. 
>>>>> OSX don't like it that way.  ;)
> 
>>>>> Each/every MainMenu.nib in all *.lproj (language) subdirs are
>>>>> affected this way.
> 
>>>>> I don't know how to fix this in Makefiles etc.  I ended up using
>>>>> Finder to drag-copy these from the real xc/ tree (not the build/
>>>>> tree) directly into the installed /Application/XDarwin.app bundle
>>>>> itself.
> 
>>>> I don't see anywhere in `make install` that would create symlinks for
>>>> these. So, I suspect this is artifact is due to a combination of the
>>>> way XCode normally operates and your use of shadow trees for builds
>>>> (a practice I highly recommend BTW).  There might be a way to coerce
>>>> XCode into following symlinks either through a command line flag, the
>>>> project file, so some other mechanism.  Please investigate.
> 
>>> There already is a bug opened that XDarwin won't build in shadow tree.
> 
>>> http://bugs.xfree86.org/show_bug.cgi?id=1182
> 
>>> As mentionned there, once the right files are copied to replace
>>> symlinks, everything go on smoothly.
> 
>>> I think the "right files" (TM)  were
>>> xc/programs/Xserver/hw/darwin/bundle
> 
>> OK.  Thanks for the info.  The attached patch should fix this.
> 
> The change I attached has now been committed.  Thanks for reporting the
> problem.
> 
> Marc.

Hi,

Took a while to get back here to report.

I built the current cvs as of the date of this msg (gee why can't
cvs just give us a simple "revision number" as svn can...).

The XDarwin.app that got installed into /Applications *again* has
the symlinks inside the MainMenu nibs for all languages.  Just to
be sure, I moved the previous build out of the way for a clean
copy to be put there.

I did this build to apply the test patches from bug #1683; I've
updated that record with good results.  A "cvs up" will show 'M'
as expected for those files that were modified from those patches
of course.  I don't think those patches had anything to do with
this problem with XDarwin.app.

The nibs built under e.g.
build2/programs/Xserver/hw/darwin/bundle/English.lproj/
have symlinks.  Shouldn't use them for bundling into the final .app.
The nibs built under e.g.
build2/programs/Xserver/hw/darwin/quartz/build/Development/XDarwin.app/Contents/Resources/English.lproj/
are OKAY.
The latter are the .lproj trees I used to "fix" the XDarwin.app
installed into /Applications manually via Finder drag&drop
directly into the .app bundle.

Wish I could help diagnose this more, this is perplexing. 
I'll try testing anything if someone comes up with something.

Thanks.