Hi,
I have made some little progress in a local branch on an OSX?aqua version of inkscape. I would like to know what the best way is to give these changes back to inkscape. Many patches? A branch on launchpad? Would a branch ~gellule-xg/inkscape/aqua work for now? Can it be made available to others later, before a merge back in master?
So far, I have workarounds for: https://bugs.launchpad.net/bugs/487144 https://bugs.launchpad.net/bugs/721448
I am also able to get rid of the launcher script used for the X11 version and put the inkscape executable directly in the application bundle. I have also started using ige-mac-integration to determine the correct paths to use throughout inkscape. I am currently working on the relocation of the libraries into the application package, one step before the production of the disk image.
Is anyone familiar with install_name_tool and the -headerpad_max_install_name or -headerpad linker flags? I might need a little help there.
-Gellule/Julien
Sorry for the delayed response (I was hoping Michael or Jon would chime in here as being those most familiar with developing and packaging inkscape on OS X).
On 15/3/11 19:27, Gellule Xg wrote:
I have made some little progress in a local branch on an OSX?aqua version of inkscape. I would like to know what the best way is to give these changes back to inkscape. Many patches? A branch on launchpad? Would a branch ~gellule-xg/inkscape/aqua work for now? Can it be made available to others later, before a merge back in master?
So far, I have workarounds for: https://bugs.launchpad.net/bugs/487144 https://bugs.launchpad.net/bugs/721448
If the changes for each bug are small, a patch (bzr diff path/to/src-file-or-directory, against current trunk) attached to each report would be fine and allow further testing.
As far as I understand, the recommended "Ubuntu/Launchpad" workflow is to create a branch for each issue, link the branch to the report and propose the branch for merging. Then the changes specific to the reported bug or feature can be tested & reviewed by members of the Inkscape developer team (who are notified about the merge proposal).
Personally, I prefer to test patches directly (if only a few number of files are modified), but others more familiar with a distributed workflow with Bazaar are likely to prefer handling separate branches for each issue.
Hopefully others - with much more experience using different workflows with bzr - will comment here as well...
Would a branch ~gellule-xg/inkscape/aqua work for now?
Just a minor footnote: personally I would avoid using 'aqua' anywhere concerning Inkscape using the Quartz backend of GTK+ - imho 'aqua' implies features & seamless desktop integration which can't be achieved: Inkscape will remain a GTK+ application even if it uses the native quartz backend of GTK+. Why not using 'inkscape-quartz' instead?
I am also able to get rid of the launcher script used for the X11 version and put the inkscape executable directly in the application bundle. I have also started using ige-mac-integration to determine the correct paths to use throughout inkscape. I am currently working on the relocation of the libraries into the application package, one step before the production of the disk image.
I'm just curious: if you "put the inkscape executable directly in the application bundle" - how do you set the required environment variables for inkscape-bin and the other modules (as is currently done in the shell script wrapper 'Contents/Resources/bin/inkscape')? Can this be done in the 'Info.plist' file?
For a new routine to create the application package (which certainly require a rewrite of the current shell scripts used), I think a separate branch would be helpful although the changes are supposed to be limited to 'packaging/macosx/*' and not affect any parts of the inkscape source code and configure scripts.
Is anyone familiar with install_name_tool and the -headerpad_max_install_name or -headerpad linker flags? I might need a little help there.
I saw your latest mail in 'macports-dev' [1] - you seem to have been able to solve it for all dependencies from MacPorts that need to be included in Inkscape.app. Currently, the packaging script relies on a custom $PREFIX for MacPorts (using a path name long enough so that all modules and libs can have their install name rewritten). In bug #532765 [2] I have proposed some changes to the fixlib() function to allow it to work with non-root custom MacPorts installation, and to fix the currently redundant looping and the incorrect ids which are created for most of the dylibs. It works fine for me (I do need those changes because the current fixlib() function doesn't work with my setup - MacPorts tree(s) installed into a separate partition (volume)).
Thank you for looking into current issues to get Inkscape work with the Quartz backend of GTK+ - as you certainly know this is a often made request by Mac users who reject or dislike programs running under X11/Xquartz.
~suv
[1] http://lists.macosforge.org/pipermail/macports-dev/2011-March/014214.html [2] https://bugs.launchpad.net/inkscape/+bug/532765
On 3/16/11 10:37 PM, ~suv wrote:
Sorry for the delayed response (I was hoping Michael or Jon would chime in here as being those most familiar with developing and packaging inkscape on OS X).
No worries. I'm finding some more rough edges as I move along.
On 15/3/11 19:27, Gellule Xg wrote:
I have made some little progress in a local branch on an OSX?aqua version of inkscape. I would like to know what the best way is to give these changes back to inkscape. Many patches? A branch on launchpad? Would a branch ~gellule-xg/inkscape/aqua work for now? Can it be made available to others later, before a merge back in master?
So far, I have workarounds for: https://bugs.launchpad.net/bugs/487144 https://bugs.launchpad.net/bugs/721448
If the changes for each bug are small, a patch (bzr diff path/to/src-file-or-directory, against current trunk) attached to each report would be fine and allow further testing.
As far as I understand, the recommended "Ubuntu/Launchpad" workflow is to create a branch for each issue, link the branch to the report and propose the branch for merging. Then the changes specific to the reported bug or feature can be tested& reviewed by members of the Inkscape developer team (who are notified about the merge proposal).
Personally, I prefer to test patches directly (if only a few number of files are modified), but others more familiar with a distributed workflow with Bazaar are likely to prefer handling separate branches for each issue.
Hopefully others - with much more experience using different workflows with bzr - will comment here as well...
Thanks. I will certainly adapt to the issue being dealt with.
Would a branch ~gellule-xg/inkscape/aqua work for now?
Just a minor footnote: personally I would avoid using 'aqua' anywhere concerning Inkscape using the Quartz backend of GTK+ - imho 'aqua' implies features& seamless desktop integration which can't be achieved: Inkscape will remain a GTK+ application even if it uses the native quartz backend of GTK+. Why not using 'inkscape-quartz' instead?
inkscape-quartz it will be, if I end up needing a branch.
I am also able to get rid of the launcher script used for the X11 version and put the inkscape executable directly in the application bundle. I have also started using ige-mac-integration to determine the correct paths to use throughout inkscape. I am currently working on the relocation of the libraries into the application package, one step before the production of the disk image.
I'm just curious: if you "put the inkscape executable directly in the application bundle" - how do you set the required environment variables for inkscape-bin and the other modules (as is currently done in the shell script wrapper 'Contents/Resources/bin/inkscape')? Can this be done in the 'Info.plist' file?
With Info.plist not being able to replace the power of a shell script that can change working directories, set relative variables... I am investigating the use of setenv/getenv directly from the executable. Apparently, there is a g_setenv/g_getenv that might be used, instead of using setenv/getenv from libc.
For a new routine to create the application package (which certainly require a rewrite of the current shell scripts used), I think a separate branch would be helpful although the changes are supposed to be limited to 'packaging/macosx/*' and not affect any parts of the inkscape source code and configure scripts.
For that part, I was thinking about a new branch indeed. And maybe put the new things in a new packaging/quartz, in parallel with the existing packaging/macosx. This is simpler for me. But a merge of the two might also be possible.
Is anyone familiar with install_name_tool and the -headerpad_max_install_name or -headerpad linker flags? I might need a little help there.
I saw your latest mail in 'macports-dev' [1] - you seem to have been able to solve it for all dependencies from MacPorts that need to be included in Inkscape.app. Currently, the packaging script relies on a custom $PREFIX for MacPorts (using a path name long enough so that all modules and libs can have their install name rewritten). In bug #532765 [2] I have proposed some changes to the fixlib() function to allow it to work with non-root custom MacPorts installation, and to fix the currently redundant looping and the incorrect ids which are created for most of the dylibs. It works fine for me (I do need those changes because the current fixlib() function doesn't work with my setup - MacPorts tree(s) installed into a separate partition (volume)).
I was hopping to be able to get macports to including something that would let anyone with a standard macports tress build inkscape. In the end, moving /opt/local to /verylooong/local, or adding -headerpad_max_install_name to the default LDFLAGS, or intercepting ld directly, works.
Thank you for looking into current issues to get Inkscape work with the Quartz backend of GTK+ - as you certainly know this is a often made request by Mac users who reject or dislike programs running under X11/Xquartz.
Thanks for the other pointers. Much appreciated.
~suv
[1] http://lists.macosforge.org/pipermail/macports-dev/2011-March/014214.html [2]https://bugs.launchpad.net/inkscape/+bug/532765
I'm just curious: if you "put the inkscape executable directly in the application bundle" - how do you set the required environment variables for inkscape-bin and the other modules (as is currently done in the shell script wrapper 'Contents/Resources/bin/inkscape')? Can this be done in the 'Info.plist' file?
With Info.plist not being able to replace the power of a shell script that can change working directories, set relative variables... I am investigating the use of setenv/getenv directly from the executable. Apparently, there is a g_setenv/g_getenv that might be used, instead of using setenv/getenv from libc.
It looks like g_setenv and g_getenv work like a charm. To make things work, I also needed to change the current working directory from the inkscape executable directly, to Contents/Resources, and the various GTK/PANGO/... configuration files to use relative path like ./lib/ or ./etc/. I had to add something to the ige-mac-integration package to do so.
Now: clean-up work before submitting patches and all.
-Julien/Gellule
On 18/03/2011, at 6:52 AM, Gellule Xg wrote:
Is anyone familiar with install_name_tool and the -headerpad_max_install_name or -headerpad linker flags? I might need a little help there.
I saw your latest mail in 'macports-dev' [1] - you seem to have been able to solve it for all dependencies from MacPorts that need to be included in Inkscape.app. Currently, the packaging script relies on a custom $PREFIX for MacPorts (using a path name long enough so that all modules and libs can have their install name rewritten). In bug #532765 [2] I have proposed some changes to the fixlib() function to allow it to work with non-root custom MacPorts installation, and to fix the currently redundant looping and the incorrect ids which are created for most of the dylibs. It works fine for me (I do need those changes because the current fixlib() function doesn't work with my setup - MacPorts tree(s) installed into a separate partition (volume)).
I was hopping to be able to get macports to including something that would let anyone with a standard macports tress build inkscape. In the end, moving /opt/local to /verylooong/local, or adding -headerpad_max_install_name to the default LDFLAGS, or intercepting ld directly, works.
Hi Gellule,
Good to hear about your progress on this.
I'm probably the best person to talk to about the install_name_tool, since I'm the main person working on the OS X packaging scripts. I think the main issue with adding -headerpad_max_install_name to the default LDFLAGS is that it needs to be done when building all the libraries in Macports on which Inkscape depends, not just for the Inkscape code itself. I found that some of these Macports libraries don't have enough space for the path rewriting. One hacky solution might be to put all the dylibs in the Inkscape.app/Contents/MacOS directory along with the inkscape executable resulting in a shorter path of just "@executable_path/libsomething.dylib". I didn't experiment too much to see exactly how long the paths could be, because it takes so long to do the path rewriting -- hence the ridiculously long suggested path currently. Even if you were to move all the libraries there, you'd still need to go about relocating all the GTK and python plugins and correcting their paths for the application.
~suv,
Thanks for your other answers,
I wasn't aware of #532765, but I'll review that for you (may take me a couple of days).
Cheers, Michael
------ Dr. Michael Wybrow, Research Fellow Clayton School of Information Technology Monash University Wellington Rd, Clayton, Vic 3800, Australia Phone: +613 9905 2479 Mobile: +614 2577 2053
Hi Gellule,
Good to hear about your progress on this.
I'm probably the best person to talk to about the install_name_tool, since I'm the main person working on the OS X packaging scripts. I think the main issue with adding -headerpad_max_install_name to the default LDFLAGS is that it needs to be done when building all the libraries in Macports on which Inkscape depends, not just for the Inkscape code itself. I found that some of these Macports libraries don't have enough space for the path rewriting. One hacky solution might be to put all the dylibs in the Inkscape.app/Contents/MacOS directory along with the inkscape executable resulting in a shorter path of just "@executable_path/libsomething.dylib". I didn't experiment too much to see exactly how long the paths could be, because it takes so long to do the path rewriting -- hence the ridiculously long suggested path currently. Even if you were to move all the libraries there, you'd still need to go about relocating all the GTK and python plugins and correcting their paths for the application.
Hi Michael,
Did you consider using ige-mac-bundler / ige-mac-integration?
For the bundling aspect, ige-mac-bundler seems to be working quite well. Currently, I have a working quartz version of Inkscape. I'm going to edit the following blueprint with what I got so far.
https://blueprints.launchpad.net/inkscape/+spec/mac-os-native
-Julien/Gellule
https://blueprints.launchpad.net/inkscape/+spec/mac-os-native
https://blueprints.launchpad.net/inkscape/+spec/inkscape-quartz Instead. At least I have control over this one. :)
-Julien/Gellule
On 21/03/2011, at 7:17 AM, Gellule Xg wrote:
Did you consider using ige-mac-bundler / ige-mac-integration?
For the bundling aspect, ige-mac-bundler seems to be working quite well.
I didn't consider it just because it didn't exist at the time. But it seems like it would make sense to use it.
Cheers, Michael
participants (3)
-
Gellule Xg -
Michael Wybrow -
~suv