help-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Debian: Cannot autobuild gnustep apps on all architectures.


From: Adam Fedor
Subject: RE: Debian: Cannot autobuild gnustep apps on all architectures.
Date: Tue, 27 Apr 2004 08:53:36 -0400


> From: Eric Heintzmann [mailto:eric@gnustep.fr.st]
> 
> On 2004-04-25 05:19:00 +0200 Adam Fedor <fedor@doc.com> wrote:
> 
> > 
> > On Apr 18, 2004, at 10:34 AM, Eric Heintzmann wrote:
> > 
> >>    Hi,
> >> When the gnustep apps are autobuilt by the official debian build 
> >> system, we 
> >> obtain sometimes build failures on some architectures (currently 
> >> only on 
> >> arm). It seems to be an issue with Info-gnustep.plist files. But I 
> >> can't 
> >> reproduce the bug on my i386.
> >> 
> >> Here logs for gworkspace on arm :
> >> 
> >> [...]
> >> echo "OLD_GNUSTEP_STAMP_ASTRING = 
> _GWorkspace-FileManager.tiff--" > 
> >> ./GWorkspace.app/stamp.make
> >> (echo "{"; echo '  NOTE = "Automatically generated, do not 
> edit!";'; 
> >> \
> >>     echo "  NSExecutable = \"GWorkspace\";"; \
> >>     echo "  NSMainNibFile = \"\";"; \
> >>     echo "  GSMainMarkupFile = \"\";"; \
> >>     if [ "FileManager.tiff" != "" ]; then \
> >>       echo "  NSIcon = \"FileManager.tiff\";"; \
> >>     fi; \
> >>     echo "  NSPrincipalClass = \"GWorkspace\";"; \
> >>     echo "}") >GWorkspace.app/Resources/Info-gnustep.plist
> >> if [ -r "GWorkspaceInfo.plist" ]; then \
> >>      plmerge GWorkspace.app/Resources/Info-gnustep.plist 
> >> "GWorkspaceInfo.plist"; \
> >>     fi
> >> 
> > 
> > It seems likely that the plmerge program is crashing for 
> some reason, 
> > but I 
> > don't know why.  I think it would be hard to fix without a 
> backtrace 
> > of it 
> > crashing.
> > 
> > 
> Since I have not an acces to an arm machine, I cannot send you a 
> backtrace. :(
> But maybe this message from Evan Prodromou can help you:
> 
> It looks to me like the build is failing when trying to make the
> APP_INFO_PROP_LIST. application.make has a call to plmerge here, and
> looking at other buildd output, it seems to throw an occasional hissy
> fit when it can't write to the user's home dir, from somewhere at
> NSUserDefaults.m.
> 
> Any suggestions? Just ride it out? It'd be nice to have an up-to-date
> Gorm in sarge.
> 


I've tried to force plmerge to fail, but I can't, even when defaults isn't 
readable/writable/doesn't exist.  Perhaps just changing application.make to 
ignore the error would work:

diff -u -r1.35 application.make
--- Instance/application.make   8 Mar 2004 14:05:04 -0000       1.35
+++ Instance/application.make   27 Apr 2004 12:50:32 -0000
@@ -259,7 +259,7 @@
          fi; \
          echo "  NSPrincipalClass = \"$(PRINCIPAL_CLASS)\";"; \
          echo "}") >$@$(END_ECHO)
-        $(ECHO_NOTHING)if [ -r "$(GNUSTEP_INSTANCE)Info.plist" ]; then \
+        -$(ECHO_NOTHING)if [ -r "$(GNUSTEP_INSTANCE)Info.plist" ]; then \
           plmerge $@ "$(GNUSTEP_INSTANCE)Info.plist"; \
          fi$(END_ECHO)
 endif


although I'm not sure how the app would behave if the plist doesn't exist. 
Maybe putting an extra

        $(ECHO_NOTHING)if [ -r "$(GNUSTEP_INSTANCE)Info.plist" ]; then \
           cp "$(GNUSTEP_INSTANCE)Info.plist" $@; \
          fi$(END_ECHO)

after that would be necessary.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]