Hi, there i spent whole day with Esteban, testing & fixing new CMake configuration on Jenkins, to integrate the changes i made for bundling VM with 3-rd party libraries ( see [1] ).
We finally made it working, as you can see in hot-backed build here: https://ci.lille.inria.fr/pharo/job/Cog-Mac-Cocoa-Esteban/72/
So, in a few days we will update the blessed branch to also use new cmake configuration(s). (right now the jobs at [2],[3] still using old configs)
Some details about changes: - changed the FT2Plugin to link dynamically with freetype library on Mac, instead of statically - changed the VM bundle directory layout: now all external plugins and dlls are stored in Contents/Plugins subdir, instead of Contents/Resources as before (see screenshot attached) - changed the external plugin search logic to search this Plugins dir instead of Resources - by default, all Mac VM's will be bundled with own version of Freetype dynamic library, - also , i will bundle NBCog VMs with cairo library by default (so, no extra installation is required)
If you want to reproduce build by own, note that on OSX 10.6. tar does not supports 7z compression, you should install it: port install gnutar port install xz ln -s /opt/local/bin/gnutar /opt/local/bin/tar (and make sure that /opt/local/bin is first in your PATH variable)
On Lion (10.7) no extra effort is required.
[1] http://computeradventures.wordpress.com/2012/06/10/bundling-vm-with-thirdpar... [2] https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/ [3] https://ci.lille.inria.fr/pharo/view/NativeBoost/
On Thu, Jun 21, 2012 at 6:25 PM, Igor Stasenko siguctua@gmail.com wrote:
Hi, there i spent whole day with Esteban, testing & fixing new CMake configuration on Jenkins, to integrate the changes i made for bundling VM with 3-rd party libraries ( see [1] ).
We finally made it working, as you can see in hot-backed build here: https://ci.lille.inria.fr/pharo/job/Cog-Mac-Cocoa-Esteban/72/
So, in a few days we will update the blessed branch to also use new cmake configuration(s). (right now the jobs at [2],[3] still using old configs)
Some details about changes:
- changed the FT2Plugin to link dynamically with freetype library on
Mac, instead of statically
- changed the VM bundle directory layout: now all external plugins
and dlls are stored in Contents/Plugins subdir, instead of Contents/Resources as before (see screenshot attached)
nice change :)
- changed the external plugin search logic to search this Plugins dir
instead of Resources
- by default, all Mac VM's will be bundled with own version of
Freetype dynamic library,
- also , i will bundle NBCog VMs with cairo library by default (so,
no extra installation is required)
If you want to reproduce build by own, note that on OSX 10.6. tar does not supports 7z compression, you should install it: port install gnutar port install xz ln -s /opt/local/bin/gnutar /opt/local/bin/tar (and make sure that /opt/local/bin is first in your PATH variable)
On Lion (10.7) no extra effort is required.
Also very cool!
Thanks guys
[1] http://computeradventures.wordpress.com/2012/06/10/bundling-vm-with-thirdpar... [2] https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/ [3] https://ci.lille.inria.fr/pharo/view/NativeBoost/
-- Best regards, Igor Stasenko.
On 2012-06-21, at 18:25, Igor Stasenko wrote:
- changed the VM bundle directory layout: now all external plugins
and dlls are stored in Contents/Plugins subdir, instead of Contents/Resources as before (see screenshot attached)
- changed the external plugin search logic to search this Plugins dir
instead of Resources
Very nice! However, what's the reason you did not put the plugins in the MacOS folder? That way a multi-platform all-in-one bundle would have only one subdirectory per platform.
- Bert -
On 21 June 2012 18:45, Bert Freudenberg bert@freudenbergs.de wrote:
On 2012-06-21, at 18:25, Igor Stasenko wrote:
- changed the VM bundle directory layout: now all external plugins
and dlls are stored in Contents/Plugins subdir, instead of Contents/Resources as before (see screenshot attached)
- changed the external plugin search logic to search this Plugins dir
instead of Resources
Very nice! However, what's the reason you did not put the plugins in the MacOS folder? That way a multi-platform all-in-one bundle would have only one subdirectory per platform.
Do you think it is important detail? I thought bundles live and die on macs.. so why caring putting it there? For iOS, we can use absolutely different layout , and for non-mac platforms it is completely unrelated...
I don't know much about bundle convention(s).. but to what i have seen, they look a bit arbitrary (i browsed multiple .app bundles).
So, if you (and others) think plugins should be under MacOS subdir, it will be easy to change that, before we put VM in use.
- Bert -
On 21 June 2012 18:55, Igor Stasenko siguctua@gmail.com wrote:
On 21 June 2012 18:45, Bert Freudenberg bert@freudenbergs.de wrote:
On 2012-06-21, at 18:25, Igor Stasenko wrote:
- changed the VM bundle directory layout: now all external plugins
and dlls are stored in Contents/Plugins subdir, instead of Contents/Resources as before (see screenshot attached)
- changed the external plugin search logic to search this Plugins dir
instead of Resources
Very nice! However, what's the reason you did not put the plugins in the MacOS folder? That way a multi-platform all-in-one bundle would have only one subdirectory per platform.
Do you think it is important detail? I thought bundles live and die on macs.. so why caring putting it there? For iOS, we can use absolutely different layout , and for non-mac platforms it is completely unrelated...
I don't know much about bundle convention(s).. but to what i have seen, they look a bit arbitrary (i browsed multiple .app bundles).
So, if you (and others) think plugins should be under MacOS subdir, it will be easy to change that, before we put VM in use.
oh, yeah.. to add: i checked multiple different bundles, and it looks like most people prefer using Contents subdir for plugins/libs than Contents/MacOS so i followed same road.
- Bert -
-- Best regards, Igor Stasenko.
On Jun 21, 2012, at 6:55 PM, Igor Stasenko wrote:
On 21 June 2012 18:45, Bert Freudenberg bert@freudenbergs.de wrote:
On 2012-06-21, at 18:25, Igor Stasenko wrote:
- changed the VM bundle directory layout: now all external plugins
and dlls are stored in Contents/Plugins subdir, instead of Contents/Resources as before (see screenshot attached)
- changed the external plugin search logic to search this Plugins dir
instead of Resources
Very nice! However, what's the reason you did not put the plugins in the MacOS folder? That way a multi-platform all-in-one bundle would have only one subdirectory per platform.
Do you think it is important detail? I thought bundles live and die on macs.. so why caring putting it there? For iOS, we can use absolutely different layout , and for non-mac platforms it is completely unrelated...
iOS builds need a very different app construction, so yes... it will not work out of the box there, but well, it is also not working now since I still didn't configure it for create vms with make (just with cmake+xcode).
Esteban
I don't know much about bundle convention(s).. but to what i have seen, they look a bit arbitrary (i browsed multiple .app bundles).
So, if you (and others) think plugins should be under MacOS subdir, it will be easy to change that, before we put VM in use.
- Bert -
-- Best regards, Igor Stasenko.
On 2012-06-21, at 18:55, Igor Stasenko wrote:
On 21 June 2012 18:45, Bert Freudenberg bert@freudenbergs.de wrote:
On 2012-06-21, at 18:25, Igor Stasenko wrote:
- changed the VM bundle directory layout: now all external plugins
and dlls are stored in Contents/Plugins subdir, instead of Contents/Resources as before (see screenshot attached)
- changed the external plugin search logic to search this Plugins dir
instead of Resources
Very nice! However, what's the reason you did not put the plugins in the MacOS folder? That way a multi-platform all-in-one bundle would have only one subdirectory per platform.
Do you think it is important detail? I thought bundles live and die on macs.. so why caring putting it there? For iOS, we can use absolutely different layout , and for non-mac platforms it is completely unrelated...
I don't know much about bundle convention(s).. but to what i have seen, they look a bit arbitrary (i browsed multiple .app bundles).
So, if you (and others) think plugins should be under MacOS subdir, it will be easy to change that, before we put VM in use.
I care about the Squeak all-in-one directory layout. On a Mac you won't see the bundle contents, but on other platforms you do. So there is e.g. Contents/MacOS, Contents/Linux-i686, etc. And because the Linux-i686 directory has the VM and all the Linux plugins, it would appear consistent if Contents/MacOS had all the Mac plugins, too.
It's not a big deal really, and the most important is to have them out of Contents/Resources, but it would seem nicer if they were in the MacOS directory.
Possibly, instead of hard-coding the path, the plugin location could be an Info.plist entry, just like we have entries for e.g. the SqueakTrustedDirectory and SqueakUnTrustedDirectory.
On a related note, it would be helpful to users if we could hide the Windows plugins in a subdirectory, too. They clutter up the root of the all-in-one considerably.
- Bert -
vm-dev@lists.squeakfoundation.org