building on a mac
Locked
 
|
Is there a page describing how to setup xcode and gcc and build on a mac? thanks. -- . .. .. ^,^ best, robert |
|
|
which vm? for Pharo: https://github.com/pharo-project/pharo-vm and see the README. cheers, Esteban
|
|
|
Is 10.6 still the required SDK? cheers -ben On Wed, Dec 16, 2015 at 1:47 AM, Esteban Lorenzano <[hidden email]> wrote: > > which vm? > for Pharo: https://github.com/pharo-project/pharo-vm > and see the README. > > cheers, > Esteban > > On 15 Dec 2015, at 18:41, Robert Withers <[hidden email]> wrote: > > Is there a page describing how to setup xcode and gcc and build on a mac? thanks. > > -- > . .. .. ^,^ best, robert > > > |
|
|
well… you can use another (I think 10.7 still works fine and 10.8 as some issues). But then you will not be compatible with older systems… Esteban > On 15 Dec 2015, at 19:12, Ben Coman <[hidden email]> wrote: > > > Is 10.6 still the required SDK? > cheers -ben > > On Wed, Dec 16, 2015 at 1:47 AM, Esteban Lorenzano <[hidden email]> wrote: >> >> which vm? >> for Pharo: https://github.com/pharo-project/pharo-vm >> and see the README. >> >> cheers, >> Esteban >> >> On 15 Dec 2015, at 18:41, Robert Withers <[hidden email]> wrote: >> >> Is there a page describing how to setup xcode and gcc and build on a mac? thanks. >> >> -- >> . .. .. ^,^ best, robert >> >> >> |
|
|
In reply to this post by Robert Withers
You should be able to build the http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/iOS/vm/SqueakPureObjc.xcodeproj Using the current Mac OS and Xcode Otherwise for cog see Sent from my iPhone
|
smime.p7s (3K) |
|
On Tue, Dec 15, 2015 at 10:38 AM, <[hidden email]> wrote:
I'm gradually moving builds across to this scene as time is available. I'm currently focussing on build.macos32x86/squeak.cog.spur & build.macos64x64/squeak.cog.spur. Anyone who moves any of the others, I'm very grateful. Just send me a tar of the changes. I'd be even more grateful for a set of makefiles that can build VM and plugins on 10.9 or 10.10 and Xcode. The Xcode project files are extremely expensive to edit :-(. For example, John put sqPlatformSpecific.h in platforms/iOS//vm/iPhone/sqPlatformSpecific.h, quite reasonably, but since then it has served for OSX too, and so belongs in platforms/iOS//vm/Common/sqPlatformSpecific.h, but making this change requires starting up Xcode on each of the project files and changing the location manually. I don't see who to automate it. Whereas if we had Makefiles it would be a simple edit script. Bah!!
_,,,^..^,,,_ best, Eliot |
|
|
In reply to this post by johnmci
Thanks everyone. I used this approach and grabbed the cog source and build the vm. The problem is I don't know how to run it nor where it is. I then went into image and built a Spur image. I now want to run the CogSpur.app with that image to generate a vm, but once again I don't know how to run an app. Could you point the way, please? robert On 12/15/2015 01:38 PM,
[hidden email] wrote:
--
. .. .. ^,^ best, robert
|
|
|
Update your SVN tree /Cog/build.macos32x86/squeak.cog.spur invoke ./miosvm -A Should build CocoaAssert.app CocoaDebug.app CocoaFast.app in that directory. On Tue, Dec 15, 2015 at 3:49 PM, Robert Withers <[hidden email]> wrote:
=========================================================================== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk =========================================================================== |
|
|
Yes, John, that’s great now. Thank you, I ran CocoaFast and tested Crypto and SecureSession. They pass (with perf tweaking). Now I would like to build with the cryptoPlugins internal. What should I do to build those? Robert
|
|
|
Hi Robert, first what's the rationale for building them internally? The current SSL plugins are external and there are advantages to them being external. Second, to build internal ones (on mac, in e.g. build.macos32x86/squeak.cog.spur) you must a) edit plugins.int to include the plugins and plugins.ext to exclude the plugins b) run Xcode on the SqueakCogSpur32x86.xcodeproj (open SqueakCogSpur32x86.xcodeproj), and add both the relevant generated code under src/plugins/*, and any support files from platforms/Cross/plugins/* or platforms/iOS/plugins/* c) use miosvm to build the VM On Tue, Dec 15, 2015 at 4:27 PM, Robert Withers <[hidden email]> wrote:
_,,,^..^,,,_ best, Eliot |
|
|
> On 15-12-2015, at 5:27 PM, Eliot Miranda <[hidden email]> wrote: > > Hi Robert, > > first what's the rationale for building them internally? The current SSL plugins are external and there are advantages to them being external. Just in case there is any idea that it would make the system ‘more secure’ remember that an external plugin of the appropriate name is supposed to over-ride any internal one; this was originally designed to allow replacing a faulty plugin without having to replace the entire VM. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Is reading in the bathroom considered Multi-Tasking? |
|
|
In reply to this post by Eliot Miranda-2
On Wed, Dec 16, 2015 at 9:27 AM, Eliot Miranda <[hidden email]> wrote: > > Hi Robert, > > first what's the rationale for building them internally? The current SSL plugins are external and there are advantages to them being external. Unikernels *may* require to static link everything. That would be easiest for a single compiled application, except since we need to pass an image to the vm we may need a file system anyway, in which was dynamic loading may be okay. Except again (much later), if a VM can request the image through the hypervisor from a backend driver, static compilation may allow the file system drivers to be culled from the unikernel. cheers -ben > Second, to build internal ones (on mac, in e.g. build.macos32x86/squeak.cog.spur) you must > a) edit plugins.int to include the plugins and plugins.ext to exclude the plugins > b) run Xcode on the SqueakCogSpur32x86.xcodeproj (open SqueakCogSpur32x86.xcodeproj), and add both the relevant generated code under src/plugins/*, and any support files from platforms/Cross/plugins/* or platforms/iOS/plugins/* > c) use miosvm to build the VM > > > On Tue, Dec 15, 2015 at 4:27 PM, Robert Withers <[hidden email]> wrote: >> >> >> Yes, John, that’s great now. Thank you, I ran CocoaFast and tested Crypto and SecureSession. They pass (with perf tweaking). >> >> Now I would like to build with the cryptoPlugins internal. What should I do to build those? >> >> Robert >> >> On Dec 15, 2015, at 7:10 PM, John McIntosh <[hidden email]> wrote: >> >> Update your SVN tree >> >> /Cog/build.macos32x86/squeak.cog.spur >> >> >> invoke >> ./miosvm -A >> >> >> Should build >> CocoaAssert.app >> CocoaDebug.app >> CocoaFast.app >> >> in that directory. >> >> >> On Tue, Dec 15, 2015 at 3:49 PM, Robert Withers <[hidden email]> wrote: >>> >>> >>> Thanks everyone. I used this approach and grabbed the cog source and build the vm. The problem is I don't know how to run it nor where it is. >>> >>> I then went into image and built a Spur image. I now want to run the CogSpur.app with that image to generate a vm, but once again I don't know how to run an app. Could you point the way, please? >>> >>> robert >>> >>> On 12/15/2015 01:38 PM, [hidden email] wrote: >>> >>> >>> >>> >>> >>> You should be able to build the http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/iOS/vm/SqueakPureObjc.xcodeproj >>> >>> Using the current Mac OS and Xcode >>> >>> Otherwise for cog see >>> http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/branches/Cog/build.macos32x86/squeak.cog.spur/makeiosvm >>> >>> >>> >>> Sent from my iPhone >>> >>> On Dec 15, 2015, at 9:41 AM, Robert Withers <[hidden email]> wrote: >>> >>> Is there a page describing how to setup xcode and gcc and build on a mac? thanks. >>> >>> -- >>> . .. .. ^,^ best, robert >>> >>> >>> -- >>> . .. .. ^,^ best, robert >>> >> >> >> >> -- >> =========================================================================== >> John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk >> =========================================================================== >> >> >> > > > > -- > _,,,^..^,,,_ > best, Eliot > |
|
|
In reply to this post by timrowledge
On Wed, Dec 16, 2015 at 9:31 AM, tim Rowledge <[hidden email]> wrote: > > >> On 15-12-2015, at 5:27 PM, Eliot Miranda <[hidden email]> wrote: >> >> Hi Robert, >> >> first what's the rationale for building them internally? The current SSL plugins are external and there are advantages to them being external. > > Just in case there is any idea that it would make the system ‘more secure’ remember that an external plugin of the appropriate name is supposed to over-ride any internal one; this was originally designed to allow replacing a faulty plugin without having to replace the entire VM. I'm curious where replacing just a faulty plugin rather than the full VM would be a practical advantage? Can this be done without shutting down the image (in which case I can see one for a high availability control system). I guess you would need to be careful to checkout the same version VM code as the starting point of a fix. cheers -ben |
|
|
> On 15-12-2015, at 5:49 PM, Ben Coman <[hidden email]> wrote: > > > On Wed, Dec 16, 2015 at 9:31 AM, tim Rowledge <[hidden email]> wrote: >> >> >>> On 15-12-2015, at 5:27 PM, Eliot Miranda <[hidden email]> wrote: >>> >>> Hi Robert, >>> >>> first what's the rationale for building them internally? The current SSL plugins are external and there are advantages to them being external. >> >> Just in case there is any idea that it would make the system ‘more secure’ remember that an external plugin of the appropriate name is supposed to over-ride any internal one; this was originally designed to allow replacing a faulty plugin without having to replace the entire VM. > > I'm curious where replacing just a faulty plugin rather than the full > VM would be a practical advantage? Can this be done without shutting > down the image (in which case I can see one for a high availability > control system). Yup, in general (subject to the design of the code using it) this is the case. You can unload a plugin with (IIRC!) Smalltalk unloadModule: name Andreas & I used to use this a great deal when originally developing the plugin concept, and it’s very useful during the new plugin process. No need to keep quitting the image/vm and so on. > I guess you would need to be careful to checkout the same version VM > code as the starting point of a fix. There’s a fair bit of latitude; in theory a plugin quite a bit newer than the code vm should be ok. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- An early example of the Peter Principle. |
|
|
In reply to this post by Ben Coman
Hi Ben,
On Tue, Dec 15, 2015 at 5:44 PM, Ben Coman <[hidden email]> wrote:
Agreed, but unikernels have a different usage profile from normal VMs where we'd like to maintain flexibility.
_,,,^..^,,,_ best, Eliot |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |