Mac OS X: osx-dmg.sh - osascript: dmg_set_style.scpt
Hello everybody,
I tried to dmg inkscape 047 X11 - but ended up with an image, which contains a link to /Applications and a folder called "Contents" - which seems not to be a .app bundle.
When running the osx-dmg.sh, I get the message:
osascript: dmg_set_style.scpt: No such file or directory
In fact, the dmg_set_style.scpt cannot be found on my machine, it looks as if it were contained by earlier source packages and dropped recently.
Could somebody be so kind and mail me the script - or - in the case - guide me to another solution of that problem.
Yours, Wolf
On 19/2/10 10:30, Wolf Drechsel wrote:
I tried to dmg inkscape 047 X11 - but ended up with an image, which contains a link to /Applications and a folder called "Contents" - which seems not to be a .app bundle.
When running the osx-dmg.sh, I get the message:
osascript: dmg_set_style.scpt: No such file or directory
In fact, the dmg_set_style.scpt cannot be found on my machine, it looks as if it were contained by earlier source packages and dropped recently.
How did you try to build the DMG file? IIRC
$ cd packaging/macosx $ ./osx-build.sh c $ ./osx-build.sh b i $ ./osx-build.sh p -py /path/to/Python-packages $ ./osx-build.sh d
worked for me [1] - option 'd' or 'distrib' executed right after creating the bundle 'Inkscape.app' i.e. without having moved Inkscape.app to a different location. The script 'osx-build.sh' should take care of setting all needed variables for osx-dmg.sh.
Admittedly I only tested it once, on Leopard. And I don't know if creating the DMG needs different settings on OS X Tiger.
~suv
[1] see my earlier posting from November: http://article.gmane.org/gmane.comp.graphics.inkscape.devel/32091
How did you try to build the DMG file? IIRC
$ cd packaging/macosx $ ./osx-build.sh c $ ./osx-build.sh b i $ ./osx-build.sh p -py /path/to/Python-packages $ ./osx-build.sh d
Arrrrgh - this was real "me" again - a simple RTFM…
Worked fine for me on Tiger as well, the package can be found in a few minutes on
http://verkehrsplanung.com/Inkscape--10.4-PPC.dmg
Thanks and greetings,
Wolf
On Fri, Feb 19, 2010 at 18:14, Wolf Drechsel <drechsel@...2249...> wrote:
http://verkehrsplanung.com/Inkscape-r22583-10.4-PPC.dmg
Yours, Wolf
Did this got posted to Sourceforge/Modevia? If not, can you do it ~suv or do you not have the appropriate permissions for it?
JiHO --- http://maururu.net
On 1/3/10 17:56, JiHO wrote:
On Fri, Feb 19, 2010 at 18:14, Wolf Drechsel <drechsel@...2249...> wrote:
http://verkehrsplanung.com/Inkscape-r22583-10.4-PPC.dmg
Yours, Wolf
Did this got posted to Sourceforge/Modevia? If not, can you do it ~suv or do you not have the appropriate permissions for it?
that's the 0.47 X11 release version for Tiger PPC that Michael already put into a DMG and uploaded to sourceforge.net some weeks ago [1] (2010-01-15) ;)
and no, I don't have permissions to upload to modevia or sf.net.
~suv
[1] http://old.nabble.com/Re%3A-0.47-X11-on-Mac-OS-X-10.4-Tiger-p27198626.html
On Mon, Mar 1, 2010 at 18:15, ~suv <suv-sf@...58...> wrote:
that's the 0.47 X11 release version for Tiger PPC that Michael already put into a DMG and uploaded to sourceforge.net some weeks ago [1] (2010-01-15) ;)
OK. I just saw this new post, dating from Feb 19, so I assumed it was a new build.
and no, I don't have permissions to upload to modevia or sf.net.
You probably should. You have commit rights now, is that correct? You could ask Bryce for sf.net (but there was some discussion about moving towards Launchpad for this too, although I remember nothing was really decided in the end) and Aaron Spike <aaron@...749...> for modevia.
JiHO --- http://maururu.net
On 1/3/10 18:28, JiHO wrote:
On Mon, Mar 1, 2010 at 18:15, ~suv <suv-sf@...58...> wrote:
that's the 0.47 X11 release version for Tiger PPC that Michael already put into a DMG and uploaded to sourceforge.net some weeks ago [1] (2010-01-15) ;)
OK. I just saw this new post, dating from Feb 19, so I assumed it was a new build.
and no, I don't have permissions to upload to modevia or sf.net.
You probably should. You have commit rights now, is that correct? You could ask Bryce for sf.net (but there was some discussion about moving towards Launchpad for this too, although I remember nothing was really decided in the end) and Aaron Spike <aaron@...749...> for modevia.
I could provide snapshot builds (Leopard, i386, X11) from current bzr trunk if I get permission to upload to modevia.
My current builds include uncommitted patches from these bug reports: Bug #171944 “to exchange position of two objects”: https://bugs.launchpad.net/inkscape/+bug/171944 Bug #376987 “Clones from blur elements are not visible in exported PDF”: https://bugs.launchpad.net/inkscape/+bug/376987
and have the experimental livepatheffects enabled.
Would I have to revert these changes for devel builds that are uploaded to modevia?
~suv
Tried to package the Intel Aqua build and ran into the following which raises a couple of points:
../../../python//ppc/2.5/numpy-1.0.4-py2.5.egg-info -> Inkscape.app/Contents/Resources/python/site-packages/ppc/2.5/numpy-1.0.4-py2.5.egg-info cp: /opt/local/etc/pango/pangox.aliases: No such file or directory Looking for dependencies. Round 1 Looking for dependencies. Round 2 Looking for dependencies. Round 3 Could not rewrite dylb paths for bundled libraries. This requires Macports to be installed in a PREFIX of at least 50 characters in length.
The package will still work if the following line is uncommented in Inkscape.app/Contents/Resources/bin/inkscape: export DYLD_LIBRARY_PATH="$TOP/lib"
Application bundle creation failed
1. My opt/local/etc/pango contains only pango.modules and pangorc. There is a pangox.aliases in the original download file for pango 1.26 but the local portfile process did not include its installation in opt/---
2. I've seen the 50 character requirement mentioned in other posts - but not sure how to accomplish this with an OSX macports install that doesn't ask a whole lot of questions about where to put things. Since I don't use macports for anything else I just have the one tree that was installed for the Inkscape effort. Can I just rename it - or duplicate it with a 50 char name?
3. The export DYLD_------ line is already uncommented in the script - I assume this is normal ( but the package doesn't work - presumably because of 1 and 2.
Thanks for any help
Stu
On 20/03/2010, at 1:20 AM, Stuart Edwards wrote:
Tried to package the Intel Aqua build and ran into the following which raises a couple of points:
../../../python//ppc/2.5/numpy-1.0.4-py2.5.egg-info -> Inkscape.app/Contents/Resources/python/site-packages/ppc/2.5/numpy-1.0.4-py2.5.egg-info cp: /opt/local/etc/pango/pangox.aliases: No such file or directory Looking for dependencies. Round 1 Looking for dependencies. Round 2 Looking for dependencies. Round 3 Could not rewrite dylb paths for bundled libraries. This requires Macports to be installed in a PREFIX of at least 50 characters in length.
The package will still work if the following line is uncommented in Inkscape.app/Contents/Resources/bin/inkscape: export DYLD_LIBRARY_PATH="$TOP/lib"
Application bundle creation failed
- My opt/local/etc/pango contains only pango.modules and pangorc. There is a pangox.aliases in the original download file for pango 1.26 but the local portfile process did not include its installation in opt/---
Strange. I'm using pango 1.24.5 on my build machine, and a "port contents pango" show that file as being installed by pango. Don't know why this shouldn't be the case for you too.
- I've seen the 50 character requirement mentioned in other posts - but not sure how to accomplish this with an OSX macports install that doesn't ask a whole lot of questions about where to put things. Since I don't use macports for anything else I just have the one tree that was installed for the Inkscape effort. Can I just rename it - or duplicate it with a 50 char name?
You can install a new Macports tree from source by downloading the source package and then doing: ./configure --prefix=/opt/local-macports-with-a-really-long-directory-name/ make sudo make install
You can't just rename the directory containing an existing macports tree as a lot of the libraries and config file have hardcoded paths in them at this point. Sorry, but you really have to do this from scratch!
- The export DYLD_------ line is already uncommented in the script - I assume this is normal ( but the package doesn't work - presumably because of 1 and 2.
It's definitely still commented out in the repository in the current head. Perhaps you uncommented it previously in your local copy?
Cheers, Michael
On 20/3/10 12:36, Michael Wybrow wrote:
On 20/03/2010, at 1:20 AM, Stuart Edwards wrote:
Tried to package the Intel Aqua build and ran into the following which raises a couple of points:
(snip)
- My opt/local/etc/pango contains only pango.modules and pangorc.
There is a pangox.aliases in the original download file for pango 1.26 but the local portfile process did not include its installation in opt/---
Strange. I'm using pango 1.24.5 on my build machine, and a "port contents pango" show that file as being installed by pango. Don't know why this shouldn't be the case for you too.
AFAIK 'pango +no_x11 +quartz' doesn't install files related to the X font backend.
~suv
- My opt/local/etc/pango contains only pango.modules and pangorc.
There is a pangox.aliases in the original download file for pango 1.26 but the local portfile process did not include its installation in opt/---
Strange. I'm using pango 1.24.5 on my build machine, and a "port contents pango" show that file as being installed by pango. Don't know why this shouldn't be the case for you too.
AFAIK 'pango +no_x11 +quartz' doesn't install files related to the X font backend.
On my aqua build there is no pangox.aliases - it's only here:
/Applications/Inkscape.app/Contents/Resources/etc/pango/pangox.aliases
but this is a X11 build, not an aqua one.
I'm quite sure you dont need pangox.aliases in an aqua build - mine doesnt have it, and it works quite nicely.
Sorry for insisting in that: There is really no output, neither in console.log, nor in crash reporter??? - That's the really interesting thing to me!
How can we launch a packaged inkscape from the command line? - I tried a
Inkscape-r9213.app/Contents/Resources/bin bub$ ./inkscape
…that launched, but most of the icons were substituted by a red cross, which is not the case normally. Hopefully, a better method of launching it from the command line will give us some hints.
Yours, Wolf
On 21/3/10 00:10, Wolf Drechsel wrote:
On 20/3/10 13:02, ~suv wrote:
On 20/3/10 12:36, Michael Wybrow wrote:
On 20/03/2010, at 1:20 AM, Stuart Edwards wrote:
- My opt/local/etc/pango contains only pango.modules and pangorc.
There is a pangox.aliases in the original download file for pango 1.26 but the local portfile process did not include its installation in opt/---
Strange. I'm using pango 1.24.5 on my build machine, and a "port contents pango" show that file as being installed by pango. Don't know why this shouldn't be the case for you too.
AFAIK 'pango +no_x11 +quartz' doesn't install files related to the X font backend.
On my aqua build there is no pangox.aliases - it's only here:
/Applications/Inkscape.app/Contents/Resources/etc/pango/pangox.aliases
but this is a X11 build, not an aqua one.
I'm quite sure you dont need pangox.aliases in an aqua build - mine doesnt have it, and it works quite nicely.
Sorry for insisting in that: There is really no output, neither in console.log, nor in crash reporter??? - That's the really interesting thing to me!
I don't understand what you are referring to - output from what?
How can we launch a packaged inkscape from the command line? - I tried a
Inkscape-r9213.app/Contents/Resources/bin bub$ ./inkscape
…that launched, but most of the icons were substituted by a red cross, which is not the case normally. Hopefully, a better method of launching it from the command line will give us some hints.
Please see bug #181639 and bug #435812 for details. To launch the packaged application from the command line:
1) don't 'cd' into the package 2) use the full path name to the launcher or to the shell wrapper script:
$ /Applications/Inkscape.app/Contents/MacOS/Inkscape
or
$ /Applications/Inkscape.app/Contents/Resources/script
3) to open a file from the command line, use its full path name, even if it is in the current directory.
hth, ~suv
Sorry for insisting in that: There is really no output, neither in console.log, nor in crash reporter??? - That's the really interesting thing to me!
I don't understand what you are referring to - output from what?
Sorry, I wrote to Stu off-list, and asked for the console.log output - and he said there is none. So my idea was to launch from the terminal and watch the output there.
- don't 'cd' into the package
- use the full path name to the launcher or to the shell wrapper
script:
$ /Applications/Inkscape.app/Contents/Resources/script
This doesnt work on my build - get the well-known
0 com.apple.AppKit 0x937d4c24 _handleWindowNeedsDisplay + 56
message
$ /Applications/Inkscape.app/Contents/MacOS/Inkscape
This works - so Stu may try this one first. BTW.: This is the output at the terminal:
bub$ Desktop/Inkscape-r9213.app/Contents/MacOS/./Inkscape Setting Language: de_DE.UTF-8 cp: /Users/bub/Desktop/Inkscape-r9213.app/Contents/Resources/etc/ pango/pangox.aliases: No such file or directory /Users/bub/.inkscape-etc/gtkrc:56: Clearlooks configuration option "menuitemstyle" is not supported and will be ignored. /Users/bub/.inkscape-etc/gtkrc:57: Clearlooks configuration option "listviewitemstyle" is not supported and will be ignored. /Users/bub/.inkscape-etc/gtkrc:58: Clearlooks configuration option "progressbarstyle" is not supported and will be ignored.
(inkscape-bin:610): Gtk-WARNING **: Das Symbol »object-visible« konnte nicht gefunden werden, ebenso wenig wie das Thema »hicolor«. Möglicherweise müssen Sie es installieren.
Yours, Wolf
Update on the Aqua Intel packaging saga. Not a direct request for help (but it's always welcome) - more of an fyi.
No success yet, but some incremental progress.
The 50 char requirement for the path to Macports was puzzling based on Wolf's statement that he used a short one. But it was definitely where osx-app.sh was failing. So on the theory of 'if in doubt, leave it out' I commented out all the offending lines (468-471 and 473-482) which basically just leaves the 'rewritelibpaths' instruction with no conditions. This runs ok and after an hour of rewriting dylib paths (actually three times before I got it to complete the task) we reach the next hurdle.
osx-app.sh exits back to osx-build.sh and I'm presented with the error: 'head: ../../.svn/entries: No such file or directory' This originates at line 268 which my almost non-existent bash scripting skills are unable to decipher. It doesn't look too critical at this stage of the game, so since the next subroutine calls osx-dmg.sh to assemble the dmg bundle - I try that as a standalone script: './osx-dmg.sh -p "Inkscape.app" ' That runs ok and creates a dmg. Unfortunately the Inkscape.app is broken - in retrospect I should have caught that by looking at the icon in the packaging/macosx directory. The dmg is 136.4 Mb and the app is 435 Mb which looks about right so we must be getting close.
One difference I notice in the contents of Inkscape.app compared to my X11 build is that Contents/MacOS is empty in the aqua build and contains a small (45kb) executable (called inkscape) in the X11 build. Executing this file opens the application, so clearly it's a critical element. I'd be interested to know how Inkscape.app determines whether it's broken or not (how does it know to put the 'no entry' sign on the icon?) - is there some sort of audit process that compares the content with a defined contents list? Also, at what point is Contents/MacOSX/inkscape file created?
Anyway, it looks as if there is something in osx-app.sh that is not going well - probably relating to the creation of the 45kb executable. More troubleshooting ----
Best
Stu
On Mar 21, 2010, at 5:03 AM, Wolf Drechsel wrote:
Sorry for insisting in that: There is really no output, neither in console.log, nor in crash reporter??? - That's the really interesting thing to me!
I don't understand what you are referring to - output from what?
Sorry, I wrote to Stu off-list, and asked for the console.log output
- and he said there is none. So my idea was to launch from the
terminal and watch the output there.
- don't 'cd' into the package
- use the full path name to the launcher or to the shell wrapper
script:
$ /Applications/Inkscape.app/Contents/Resources/script
This doesnt work on my build - get the well-known
0 com.apple.AppKit 0x937d4c24 _handleWindowNeedsDisplay + 56
message
$ /Applications/Inkscape.app/Contents/MacOS/Inkscape
This works - so Stu may try this one first. BTW.: This is the output at the terminal:
bub$ Desktop/Inkscape-r9213.app/Contents/MacOS/./Inkscape Setting Language: de_DE.UTF-8 cp: /Users/bub/Desktop/Inkscape-r9213.app/Contents/Resources/etc/ pango/pangox.aliases: No such file or directory /Users/bub/.inkscape-etc/gtkrc:56: Clearlooks configuration option "menuitemstyle" is not supported and will be ignored. /Users/bub/.inkscape-etc/gtkrc:57: Clearlooks configuration option "listviewitemstyle" is not supported and will be ignored. /Users/bub/.inkscape-etc/gtkrc:58: Clearlooks configuration option "progressbarstyle" is not supported and will be ignored.
(inkscape-bin:610): Gtk-WARNING **: Das Symbol »object-visible« konnte nicht gefunden werden, ebenso wenig wie das Thema »hicolor«. Möglicherweise müssen Sie es installieren.
Yours, Wolf
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 21/3/10 15:33, Stuart Edwards wrote:
Update on the Aqua Intel packaging saga. Not a direct request for help (but it's always welcome) - more of an fyi.
No success yet, but some incremental progress.
The 50 char requirement for the path to Macports was puzzling based on Wolf's statement that he used a short one. But it was definitely where osx-app.sh was failing. So on the theory of 'if in doubt, leave it out' I commented out all the offending lines (468-471 and 473-482) which basically just leaves the 'rewritelibpaths' instruction with no conditions. This runs ok and after an hour of rewriting dylib paths (actually three times before I got it to complete the task) we reach the next hurdle.
This will not work. Please undo all your changes to osx-app.sh and do as the script tells you if it fails to rewrite the paths to the linked shared libs: after building Inkscape.app, edit 'Inkscape.app/Contents/Resources/bin/inkscape' and uncomment the line with 'DYLD_LIBRARY_PATH' as told by the error message.
Applying the rewritelibpaths{} function when the linked shared libs have been built with a shorter pathname (i.e. MacPorts default prefix '/opt/local') will fail, if not during rewriting then at runtime.
If you really want to create Inkscape.app with the all lib paths rewritten you have to start from scratch and completely rebuild your MacPorts tree after installing MacPorts itself from source with a custom prefix - just as Michael explained in his earlier answer.
osx-app.sh exits back to osx-build.sh and I'm presented with the error: 'head: ../../.svn/entries: No such file or directory' This originates at line 268 which my almost non-existent bash scripting skills are unable to decipher.
ignore the warning about missing svn entries, IIRC it's not critical at this stage.
It doesn't look too critical at this stage of the game, so since the next subroutine calls osx-dmg.sh to assemble the dmg bundle - I try that as a standalone script: './osx-dmg.sh -p "Inkscape.app" ' That runs ok and creates a dmg. Unfortunately the Inkscape.app is broken - in retrospect I should have caught that by looking at the icon in the packaging/macosx directory. The dmg is 136.4 Mb and the app is 435 Mb which looks about right so we must be getting close.
I would recommend to do one step at a time only. Why build a DMG if you don't have a working Inkscape.app yet?
One difference I notice in the contents of Inkscape.app compared to my X11 build is that Contents/MacOS is empty in the aqua build and contains a small (45kb) executable (called inkscape) in the X11 build. Executing this file opens the application, so clearly it's a critical element.
The application will not start if the launcher binary is missing. I don't know what went wrong - you should have seen related error messages in the output from osx-build.sh.
I'd be interested to know how Inkscape.app determines whether it's broken or not (how does it know to put the 'no entry' sign on the icon?) - is there some sort of audit process that compares the content with a defined contents list? Also, at what point is Contents/MacOSX/inkscape file created?
It is the first thing that's built when running
$ osx-build.sh p -py /path/to/Python-packages
and the output of this process is usually very verbose ;)
See lines 239-249 in 'osx-app.sh' (assuming you are building from the 0.47 tarball release): here 'xcodebuild' is called to build the launcher as a native osx app. Do you have an up-to-date and complete Xcode installation?
Anyway, it looks as if there is something in osx-app.sh that is not going well - probably relating to the creation of the 45kb executable. More troubleshooting ----
~suv
thanks for the prompt reply -- plenty to think about.
On Mar 21, 2010, at 12:35 PM, ~suv wrote:
On 21/3/10 15:33, Stuart Edwards wrote:
Update on the Aqua Intel packaging saga. Not a direct request for help (but it's always welcome) - more of an fyi.
No success yet, but some incremental progress.
The 50 char requirement for the path to Macports was puzzling based on Wolf's statement that he used a short one. But it was definitely where osx-app.sh was failing. So on the theory of 'if in doubt, leave it out' I commented out all the offending lines (468-471 and 473-482) which basically just leaves the 'rewritelibpaths' instruction with no conditions. This runs ok and after an hour of rewriting dylib paths (actually three times before I got it to complete the task) we reach the next hurdle.
This will not work. Please undo all your changes to osx-app.sh and do as the script tells you if it fails to rewrite the paths to the linked shared libs: after building Inkscape.app, edit 'Inkscape.app/Contents/Resources/bin/inkscape' and uncomment the line with 'DYLD_LIBRARY_PATH' as told by the error message.
Applying the rewritelibpaths{} function when the linked shared libs have been built with a shorter pathname (i.e. MacPorts default prefix '/opt/local') will fail, if not during rewriting then at runtime.
If you really want to create Inkscape.app with the all lib paths rewritten you have to start from scratch and completely rebuild your MacPorts tree after installing MacPorts itself from source with a custom prefix - just as Michael explained in his earlier answer.
ok -
osx-app.sh exits back to osx-build.sh and I'm presented with the error: 'head: ../../.svn/entries: No such file or directory' This originates at line 268 which my almost non-existent bash scripting skills are unable to decipher.
ignore the warning about missing svn entries, IIRC it's not critical at this stage.
this appears to be more than a warning - the file can't be found, the script terminates.
It doesn't look too critical at this stage of the game, so since the next subroutine calls osx-dmg.sh to assemble the dmg bundle - I try that as a standalone script: './osx-dmg.sh -p "Inkscape.app" ' That runs ok and creates a dmg. Unfortunately the Inkscape.app is broken - in retrospect I should have caught that by looking at the icon in the packaging/macosx directory. The dmg is 136.4 Mb and the app is 435 Mb which looks about right so we must be getting close.
I would recommend to do one step at a time only. Why build a DMG if you don't have a working Inkscape.app yet?
As I said, I didn't pick up on the broken app until later - too busy trying to work through the scritps
One difference I notice in the contents of Inkscape.app compared to my X11 build is that Contents/MacOS is empty in the aqua build and contains a small (45kb) executable (called inkscape) in the X11 build. Executing this file opens the application, so clearly it's a critical element.
The application will not start if the launcher binary is missing. I don't know what went wrong - you should have seen related error messages in the output from osx-build.sh.
on closer inspection - here's what happens when I run osx-build.sh:
SEsMacPro:macosx stu$ ./osx-build.sh p -py ../../../python/
CREATE INKSCAPE APP BUNDLE
Removing previous Inkscape.app Building launcher...
=== CLEAN NATIVE TARGET ScriptExec OF PROJECT ScriptExec WITH CONFIGURATION Deployment === Check dependencies [BEROR]error: There is no SDK with the name or path '/Developer/SDKs/MacOSX10.4u.sdk' Clean.Remove clean build/Deployment/ScriptExec.app /bin/rm -rf /Users/stu/inkscape_port/inkscape-0.47/packaging/macosx/ScriptExec/build/Deployment/ScriptExec.app
Clean.Remove clean build/ScriptExec.build/Deployment/ScriptExec.build /bin/rm -rf /Users/stu/inkscape_port/inkscape-0.47/packaging/macosx/ScriptExec/build/ScriptExec.build/Deployment/ScriptExec.build
** CLEAN SUCCEEDED **
=== BUILD NATIVE TARGET ScriptExec OF PROJECT ScriptExec WITH CONFIGURATION Deployment === Check dependencies error: There is no SDK with the name or path '/Developer/SDKs/MacOSX10.4u.sdk' [BEROR]error: There is no SDK with the name or path '/Developer/SDKs/MacOSX10.4u.sdk' ** BUILD FAILED **
cp: /Users/stu/inkscape_port/inkscape-0.47/packaging/macosx/ScriptExec/build/Deployment/ScriptExec.app/Contents/MacOS/ScriptExec: No such file or directory
Filling app bundle...
/Users/stu/inkscape_port/inkscape-0.47/packaging/macosx/../../Build//bin/inkscape -> Inkscape.app/Contents/Resources/bin/inkscape-bin building file list ... done clipart/ etc, etc
Is the lack of MacOSX10.4u.sdk significant? My SDK file only contains 10.5 and 10.6.sdk. The reason for the missing launcher binary? Since the build apparently fails at this point, why does the script not terminate (as it seems to at other locations)?
I'd be interested to know how Inkscape.app determines whether it's broken or not (how does it know to put the 'no entry' sign on the icon?) - is there some sort of audit process that compares the content with a defined contents list? Also, at what point is Contents/MacOSX/inkscape file created?
It is the first thing that's built when running
$ osx-build.sh p -py /path/to/Python-packages
and the output of this process is usually very verbose ;)
indeed
See lines 239-249 in 'osx-app.sh' (assuming you are building from the 0.47 tarball release): here 'xcodebuild' is called to build the launcher as a native osx app.
ok - I see it now.
Do you have an up-to-date and complete Xcode installation?
AFIK -- 3.2.1
Stu
On 21/3/10 18:38, Stuart Edwards wrote:
thanks for the prompt reply -- plenty to think about.
On Mar 21, 2010, at 12:35 PM, ~suv wrote:
On 21/3/10 15:33, Stuart Edwards wrote:
osx-app.sh exits back to osx-build.sh and I'm presented with the error: 'head: ../../.svn/entries: No such file or directory' This originates at line 268 which my almost non-existent bash scripting skills are unable to decipher.
ignore the warning about missing svn entries, IIRC it's not critical at this stage.
this appears to be more than a warning - the file can't be found, the script terminates.
no, the script doesn't terminate. The variable $REVISION is empty because the command on line 268 in osx-build.sh fails, but the script continues - this error does not prevent you from configuring the source tree, building inkscape and packaging Inkscape.app.
One difference I notice in the contents of Inkscape.app compared to my X11 build is that Contents/MacOS is empty in the aqua build and contains a small (45kb) executable (called inkscape) in the X11 build. Executing this file opens the application, so clearly it's a critical element.
The application will not start if the launcher binary is missing. I don't know what went wrong - you should have seen related error messages in the output from osx-build.sh.
on closer inspection - here's what happens when I run osx-build.sh:
SEsMacPro:macosx stu$ ./osx-build.sh p -py ../../../python/
<snipped>
=== BUILD NATIVE TARGET ScriptExec OF PROJECT ScriptExec WITH CONFIGURATION Deployment === Check dependencies error: There is no SDK with the name or path '/Developer/SDKs/MacOSX10.4u.sdk' [BEROR]error: There is no SDK with the name or path '/Developer/SDKs/MacOSX10.4u.sdk' ** BUILD FAILED **
<snipped>
Is the lack of MacOSX10.4u.sdk significant? My SDK file only contains 10.5 and 10.6.sdk. The reason for the missing launcher binary? Since the build apparently fails at this point, why does the script not terminate (as it seems to at other locations)?
Sorry, I was under the impression that you are using Mac OS X 10.5 Leopard, not Snow Leopard.
Yes, the lack of MacOSX10.4u.sdk is obviously significant for the available xcodeproject of the application launcher. Please be aware that the release version 0.47 was not built on Snow Leopard, nor are the current development snapshots built on Snow Leopard. I.e. you are trying to do something new that seems to require part of the packaging modules to be modified and updated to run on OS X 10.6 Snow Leopard.
I recommend to file a bug report, detailing the SL related errors you see when trying to package the application. Please include all relevant information about your OS and Xcode version.
The GTK+/Quartz (so-called "Aqua") version will also require changes to both the build scripts and the launcher scripts - but this should be handled in a separate bug report, similar to the one Wolf filed for removing the code launching X11 on Tiger [1].
Do you have an up-to-date and complete Xcode installation?
AFIK -- 3.2.1
Did you check if MacOSX10.4u.sdk is available as optional install for Xcode 3.2.x?
~suv
[1] Bug #528232 “Mac OS X: X11 is launched at inkscape aqua startup” https://bugs.launchpad.net/inkscape/+bug/528232
On 21/3/10 10:03, Wolf Drechsel wrote:
$ /Applications/Inkscape.app/Contents/MacOS/Inkscape
This works - so Stu may try this one first. BTW.: This is the output at the terminal:
bub$ Desktop/Inkscape-r9213.app/Contents/MacOS/./Inkscape Setting Language: de_DE.UTF-8 cp: /Users/bub/Desktop/Inkscape-r9213.app/Contents/Resources/etc/ pango/pangox.aliases: No such file or directory
see earlier mails.
/Users/bub/.inkscape-etc/gtkrc:56: Clearlooks configuration option "menuitemstyle" is not supported and will be ignored. /Users/bub/.inkscape-etc/gtkrc:57: Clearlooks configuration option "listviewitemstyle" is not supported and will be ignored. /Users/bub/.inkscape-etc/gtkrc:58: Clearlooks configuration option "progressbarstyle" is not supported and will be ignored.
These warnings happen because some of the settings in Inkscape's custom GTK+ theme no longer work with the new version of the Clearlooks engine you updated to (the one from gtk-engines2). I see the same warnings on Leopard (GTK+/X11) (see also bug #539075 [1] and #524496 [2]).
Until we have updated the resource file that gets packaged with Inkscape.app you can comment (insert a '#') lines 56-58 in
packaging/macosx/Resources/themes/Clearlooks-Quicksilver-OSX/gtk-2.0/pre_gtkrc
before building Inkscape.app, or edit the resource file in your existing app:
Inkscape.app/Contents/Resources/themes/Clearlooks-Quicksilver-OSX/gtk-2.0/pre_gtkrc
(inkscape-bin:610): Gtk-WARNING **: Das Symbol »object-visible« konnte nicht gefunden werden, ebenso wenig wie das Thema »hicolor«. Möglicherweise müssen Sie es installieren.
known, but harmless warning. Should have been fixed with bug #446842 [3] but there are some changes needed so that the packaging process on osx can actually pick up the added file. Until then you can fix it locally by adding a new folder 'hicolor' with an empty file called 'index.theme' in 'Build/share/inkscape/icons' before you rebuild Inkscape.app or do the same inside your existing Inkscape.app:
$ mkdir Inkscape.app/Contents/Resources/icons/hicolor $ touch Inkscape.app/Contents/Resources/icons/hicolor/index.theme
hth, ~suv
[1] https://bugs.launchpad.net/inkscape/+bug/539075 [2] https://bugs.launchpad.net/inkscape/+bug/524496 [3] https://bugs.launchpad.net/inkscape/+bug/446842
Stuart Edwards <sedwards2@...360...> writes:
Tried to package the Intel Aqua build and ran into the following which raises a couple of points:
Looking for dependencies. Round 1 Looking for dependencies. Round 2 Looking for dependencies. Round 3 Could not rewrite dylb paths for bundled libraries. This requires Macports to be installed in a PREFIX of at least 50 characters in length.
The package will still work if the following line is uncommented in Inkscape.app/Contents/Resources/bin/inkscape: export DYLD_LIBRARY_PATH="$TOP/lib"
Application bundle creation failed
Thanks for any help
Stu
There appears to be a bug in osx-app.sh... on line 469 replace:
if [ "$PATHLENGTH" -ge "50" ]; then
with
if [ "$PATHLENGHT" -le "50" ]; then
the -ge meant GREATER OR EQUAL when it should have been LESS OR EQUAL. A great big oops.
Cheers,
Lloyd
P.S. My built app still doesn't work :(
On 7/4/10 21:16, Lloyd Sargent wrote:
Stuart Edwards <sedwards2@...360...> writes:
Tried to package the Intel Aqua build and ran into the following which raises a couple of points:
Looking for dependencies. Round 1 Looking for dependencies. Round 2 Looking for dependencies. Round 3 Could not rewrite dylb paths for bundled libraries. This requires Macports to be installed in a PREFIX of at least 50 characters in length.
The package will still work if the following line is uncommented in Inkscape.app/Contents/Resources/bin/inkscape: export DYLD_LIBRARY_PATH="$TOP/lib"
Application bundle creation failed
There appears to be a bug in osx-app.sh... on line 469 replace:
if [ "$PATHLENGTH" -ge "50" ]; then
with
if [ "$PATHLENGHT" -le "50" ]; then
the -ge meant GREATER OR EQUAL when it should have been LESS OR EQUAL. A great big oops.
No, the script is correct: you can't use rewritelibpaths() if the LIBPREFIX path is not long enough.
If you did install MacPorts with the default prefix '/opt/local' you have to uncomment the line with DYLD_LIBRARY_PATH to get a working Inkscape.app.
~suv
references: http://article.gmane.org/gmane.comp.graphics.inkscape.devel/31325 http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/annotate/head%3A/pa...
On 19/2/10 10:30, Wolf Drechsel wrote:
I tried to dmg inkscape 047 X11 - but ended up with an image, which contains a link to /Applications and a folder called "Contents" - which seems not to be a .app bundle.
When running the osx-dmg.sh, I get the message:
osascript: dmg_set_style.scpt: No such file or directory
In fact, the dmg_set_style.scpt cannot be found on my machine, it looks as if it were contained by earlier source packages and dropped recently.
Could somebody be so kind and mail me the script - or - in the case - guide me to another solution of that problem.
follow-up with the link to the 0.47 'dmg_set_style.scpt' script file - is it really missing from the source tar ball?
Just in case - you can download it directly from the 'packaging/macosx' bzr repository for the 0.47 release branch: http://bazaar.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_47_BRANCH/files/head%3A/packaging/macosx/
~suv
participants (6)
-
JiHO -
Lloyd Sargent -
Michael Wybrow -
Stuart Edwards -
Wolf Drechsel -
~suv