Hi Tim R.
Could you please define the deliverables for this project so I make sure I meet them?
Unless I a missing something obvious, do not think I will be able to build on the Mac/IOS trees due to my platform being Linux.
My next task is to get all the "missing plugins" that pharo has moved to squeak and following that, do the build tree revamp for Eliot.
Following that is Windows builds (however that is done)
Thanks for your time.
tty
Hi, well first of all congratulations and thank you for banging on this.
On 27-05-2014, at 1:10 PM, gettimothy gettimothy@zoho.com wrote:
Hi Tim R.
Could you please define the deliverables for this project so I make sure I meet them?
The key issue is ending up with a cmake build system that works within the needs we’ve listed in various mails; just like the autoconf stuff you have to be able to svn a tree, type ‘make’ and it does all the configuration testing, assembling of any files that need building (like plugins.exc for example) and then builds the vm. There must be no need to run an image to generate anything at this stage. If you want to make it that an in-image tool can be used to generate the cmake files rather than hand-writing them, I don’t care either way but the cmake files must be saved in svn and do the full job. Ian already has the working example of the plain interpreter vm code tree and whatever we end up with for the cog tree should be very, very similar just with the cog extra stuff. The long term aim is to merge the trees very thoroughly so that the plain interp and various cog versions are all peers. There’s a fair way to go for that though.
Unless I a missing something obvious, do not think I will be able to build on the Mac/IOS trees due to my platform being Linux.
Since neither platform uses autoconf there is no need to convert them to cmake… likewise you don’t need to do anything to the RISC OS build system ;-)
My next task is to get all the "missing plugins" that pharo has moved to squeak and following that, do the build tree revamp for Eliot.
Following that is Windows builds (however that is done)
No idea about Windows and more to the point I don’t really care. If it uses autoconf within the mingw tools then I suppose it might be possible to convert to cmake? Not an issue for me but I imagine Eliot would be happy if it were nicer.
Thanks for your time.
No, thank you for yours.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Sailboat fuel for brains.
Hi Tim.
Thank you for the reply.
The key issue is ending up with a cmake build system that works within the needs we’ve listed in various mails; just like the autoconf stuff you have to be able to svn a tree, type ‘make’ and it does all the configuration testing, assembling of any files that need building (like plugins.exc for example) and then builds the vm. There must be no need to run an image to generate anything at this stage. If you want to make it that an in-image tool can be used to generate the cmake files rather than hand-writing them, I don’t care either way but the cmake files must be saved in svn and do the full job. Ian already has the working example of the plain interpreter vm code tree and whatever we end up with for the cog tree should be very, very similar just with the cog extra stuff. The long term aim is to merge the trees very thoroughly so that the plain interp and various cog versions are all peers. There’s a fair way to go for that though.
This is ready to test on the Linux configs for both Cog and Stack VM's.
Its the testing infrastructure that has me stumped at the moment. I am assuming these tools will be hosted on a server and jobs run to produce the build files. I don't know who to work with to get that done.
I do have my home machine configured as an SVN server if needed and we can do that from there if you like.
My testing abilities here at home are for windowsXP 32 and linux32 standard. My tests on my home box work fine for Unix64 with 32 bit compat libs.
My problem is identifiying WHAT new configurations to create and WHERE to test them.
The CMake configurations currently available to generate (with or without source generation) are :
-------------------------Cog VM Configurations-------------------------
SqueakCogMTUnixConfig generateWithSources. SqueakCogMTUnixConfig generate.
SqueakCogOnDebian64Config generateWithSources SqueakCogOnDebian64Config generate
SqueakCogUnixDebugConfig generateWithSources SqueakCogUnixDebugConfig generate
SqueakCogUnixNoGLConfig generateWithSources. SqueakCogUnixNoGLConfig generate
-------------------------Stack VM Configurations using a builder------------------------- SqueakStackVMBuilder buildSlackwareUnix64w32Libs SqueakStackVMBuilder buildSlackwareUnix64w32LibsNoGL
-------------------------Stack VM configurations------------------------- SqueakStackCrossRaspbianConfig generateWithSources SqueakStackCrossRaspbianConfig generate
SqueakStackRaspbianFastBltConfig generateWithSources SqueakStackCrossRaspbianFastBltConfig generate
SqueakStackRaspbianConfig generateWithSources SqueakStackRaspbianConfig generate
SqueakStackRaspbianFastBltConfig generateWithSources SqueakStackRaspbianFastBltConfig generate
SqueakStackUnixDebugConfig generateWithSources SqueakStackUnixDebugConfig generate
SqueakStackEvtAndroidConfig generate ""
-------------------------BSD configs------------------------- SqueakCogFreeBSDConfig generateWithSources
-------------------------SunOS configs------------------------- SqueakCogFreeBSDConfig generateWithSources
-------------------------MacOS Configurations-------------------------
SqueakCogMacOSConfig generateWithSources. SqueakCogMacOSConfig generate.
SqueakCogMacOSDebugConfig generateWithSources. SqueakCogMacOSDebugConfig generate.
SqueakCogMTMacOSConfig generateWithSources. SqueakCogMTMacOSConfig generate.
SqueakStackMacOSConfig generateWithSources. SqueakStackMacOSConfig generate.
SqueakStackMacOSDebugConfig generateWithSources. SqueakStackMacOSDebugConfig generate.
-------------------------IOS Configurations-------------------------
SqueakCogCocoaIOSConfig generateWithSources SqueakCogCocoaIOSConfig generate
SqueakCogMTCocoaIOSConfig generateWithSources SqueakCogMTCocoaIOSConfig generate
SqueakStackCocoaIOSConfig generateWithSources SqueakStackCocoaIOSConfig generate
SqueakStackCocoaIOSCLANGConfig generateWithSources SqueakStackCocoaIOSCLANGConfig generate
SqueakStackIPhoneConfig generateWithSources SqueakStackIPhoneConfig generate
SqueakStackIPhoneSimulatorConfig generateWithSources SqueakStackIPhoneSimulatorConfig generate
-------------------------Windows configs------------------------- SqueakCogWindowsConfig generateWithSources SqueakCogWindowsConfig generate.
SqueakCogMTWindowsConfig generateWithSources SqueakCogMTWindowsConfig generate
SqueakCogWindowsDebugConfig generateWithSources. SqueakCogWindowsDebugConfig generate.
SqueakStackWindowsConfig generateWithSources SqueakStackWindowsConfig generate
I am discussing with Eliot revamping the build tree hierarchy for builds--maybe that will kill two birds with one stone.....
Are you ok with using my SVN repository for testing? Its here: http://www.svn.menmachinesmaterials.com/Cog/Cog/
I can port Eliot's build tree and at the same time create a CMake configuration for it (in a parallel cmake_ directory for now).
What do you guys think?
vm-dev@lists.squeakfoundation.org