Want to make $1000.00 (that’s one thousand USD in case I mistyped the number of zeros) and be a hero?
I’m seriously not interested in delving into the insanity of either automake nor cmake; my experiences thus far have left scars. So, in order to avoid pain whilst getting a Cog/stackvm build system that gets reasonably close to that in place for the plain interpreter (see squeakvm.org) - with a side aim of eventually merging - I am offering some money.
For someone that actually knows this stuff I suspect it is an easy, if perhaps long-winded, job. The acceptance test that determines when payment can be made would be a) Eliot & Ian agreeing that it is good enough to replace the auto-blargh horror that is currently in use (that’s a pretty high bar) and b) successful addition of the Raspberry Pi faster-blt code to the cog/stack build, as with the current plain interpreter build
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Canis meus id comedit = My dog ate it.
Are you aware that you asking for something which already done and exists?
http://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-usi...
https://github.com/pharo-project/pharo-vm
On 31 October 2013 21:16, tim Rowledge tim@rowledge.org wrote:
Want to make $1000.00 (that’s one thousand USD in case I mistyped the number of zeros) and be a hero?
I’m seriously not interested in delving into the insanity of either automake nor cmake; my experiences thus far have left scars. So, in order to avoid pain whilst getting a Cog/stackvm build system that gets reasonably close to that in place for the plain interpreter (see squeakvm.org) - with a side aim of eventually merging - I am offering some money.
For someone that actually knows this stuff I suspect it is an easy, if perhaps long-winded, job. The acceptance test that determines when payment can be made would be a) Eliot & Ian agreeing that it is good enough to replace the auto-blargh horror that is currently in use (that’s a pretty high bar) and b) successful addition of the Raspberry Pi faster-blt code to the cog/stack build, as with the current plain interpreter build
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Canis meus id comedit = My dog ate it.
On 31 October 2013 21:21, Igor Stasenko siguctua@gmail.com wrote:
Are you aware that you asking for something which already done and exists?
http://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-usi...
https://github.com/pharo-project/pharo-vm
so, even if it doesn't works for Raspberry Pi it will be much less work
by just adding yet another config in CMakeVMMaker package comparing to implementing whole thing from scratch.
(Btw, i remember there was work on building Cog Stack VM on Raspberry Pi, but i don't know details in what state it is. @JB, care to share)?
On 31 October 2013 21:16, tim Rowledge tim@rowledge.org wrote:
Want to make $1000.00 (that’s one thousand USD in case I mistyped the number of zeros) and be a hero?
I’m seriously not interested in delving into the insanity of either automake nor cmake; my experiences thus far have left scars. So, in order to avoid pain whilst getting a Cog/stackvm build system that gets reasonably close to that in place for the plain interpreter (see squeakvm.org) - with a side aim of eventually merging - I am offering some money.
For someone that actually knows this stuff I suspect it is an easy, if perhaps long-winded, job. The acceptance test that determines when payment can be made would be a) Eliot & Ian agreeing that it is good enough to replace the auto-blargh horror that is currently in use (that’s a pretty high bar) and b) successful addition of the Raspberry Pi faster-blt code to the cog/stack build, as with the current plain interpreter build
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Canis meus id comedit = My dog ate it.
-- Best regards, Igor Stasenko.
On 31-10-2013, at 1:30 PM, Igor Stasenko siguctua@gmail.com wrote:
(Btw, i remember there was work on building Cog Stack VM on Raspberry Pi, but i don't know details in what state it is. @JB, care to share)?
I did it 6 months ago. I’m running it right now. All the code is in the appropriate places on squeakvm.org
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Virtual Memory" means never knowing where your next byte is coming from.
On 31 October 2013 21:40, tim Rowledge tim@rowledge.org wrote:
On 31-10-2013, at 1:30 PM, Igor Stasenko siguctua@gmail.com wrote:
(Btw, i remember there was work on building Cog Stack VM on Raspberry Pi, but i don't know details in what state it is. @JB, care to share)?
I did it 6 months ago. I’m running it right now. All the code is in the appropriate places on squeakvm.org
yes but it does not using cmake (or any other common building process to
build VM on all platforms), while i talking about cmake everywhere (or at least using CMakeVMMaker as a part of build/configuring process).
as in [1], it doesn't using cmake, but still automates things up to the level where you can build VM fully automatically.
https://github.com/pharo-project/pharo-vm/tree/master/mc/CMakeVMMaker.packag...
still i'm not aware of full details about work being done there, so i think i'd better shut up and let original authors of that work stand up and share details.
tim
-- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Virtual Memory" means never knowing where your next byte is coming from.
On 31-10-2013, at 1:21 PM, Igor Stasenko siguctua@gmail.com wrote:
Are you aware that you asking for something which already done and exists?
It’s not already done; it isn’t what is included by Ian on squeakvm,org nor eliot on … wherever. If you can convince both of them that it should be, then you win the bounty. I’m not actually much interested in details here; just the result of getting the plain interpreter code on squeakvm.org (which is currently an SVN repository not git) and Eliot’s code (also on squeakvm.org) built by substantially the same mechanism.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim May the bugs of many programs nest on your hard drive.
On 31 October 2013 21:38, tim Rowledge tim@rowledge.org wrote:
On 31-10-2013, at 1:21 PM, Igor Stasenko siguctua@gmail.com wrote:
Are you aware that you asking for something which already done and
exists?
It’s not already done; it isn’t what is included by Ian on squeakvm,org nor eliot on … wherever. If you can convince both of them that it should be, then you win the bounty. I’m not actually much interested in details here; just the result of getting the plain interpreter code on squeakvm.org (which is currently an SVN repository not git) and Eliot’s code (also on squeakvm.org) built by substantially the same mechanism.
ah. you also want vanilla squeak VM built by that.. well, originally CMakeVMMaker was envisioned to support that. but it was never tried/done, yet it is certainly doable ( and again at a fraction of effort comparing to doing everything from scratch).
But no, i'm not going to run for a bounty nor attempt to convince anyone to use/build on top of CMakeVMMaker (apparently because i tried this before and failed).
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim May the bugs of many programs nest on your hard drive.
Hey Tim,
Göran and Eliot have been discussing this. I just talked to Eliot about it yesterday. He said he was happy to support cmake but didn't want to have to do the work himself. I'm hoping that the work Göran is doing on this now can be turned over to Eliot when it is finished. I think there is agreement that combining the excellent work of pharo build with Eliot's new vm work is a very good thing to do. The work to merge the build environments is already being done at 3D ICC. We are working on this for the Mac also but have not discussed it with Ian yet.
Ron Teitelbaum
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of tim Rowledge Sent: Wednesday, November 06, 2013 9:04 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build
process
Wow, no interest? Is it because make is painful or because nobody needs to make any more money?
tim
Hey Tim and all, On 07.11.2013, at 05:00, Ron Teitelbaum ron@usmedrec.com wrote:
Hey Tim,
Göran and Eliot have been discussing this. I just talked to Eliot about it yesterday. He said he was happy to support cmake but didn't want to have to do the work himself. I'm hoping that the work Göran is doing on this now can be turned over to Eliot when it is finished. I think there is agreement that combining the excellent work of pharo build with Eliot's new vm work is a very good thing to do. The work to merge the build environments is already being done at 3D ICC. We are working on this for the Mac also but have not discussed it with Ian yet.
Ron Teitelbaum
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of tim Rowledge Sent: Wednesday, November 06, 2013 9:04 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build
process
Wow, no interest? Is it because make is painful or because nobody needs to make any more money?
I actually have interest but I am currently reluctant, for time-capturing reasons in my personal and work life.
However, Here is what I would do:
• Start from Ians CMake work, and try to generalize it for the non-Linux platforms • Windows would be kind-of straight-forward, • For OS X, I would really want to have the Cocoa-based VM stuff (aka Squeak VM 5.4.7.x) integrated and proper Xcode files generated, especially to be able to have iOS VMs built automatically. Here, some information from John McIntosh would be helpfull, especially a simple walk-through. I have some experience with that[1]
Despite all admiration I have for the way the PharoVM is built, there is one thing that bothers me: • You first somehow generate the VM sources (which is fine, and the automated way is amazing) • THEN, the a Script generates CMake-Files • CMake then generates Makefiles • and then finally a vm is compiled. This is one generating step too much, for my taste. Personally, I'd prefer CMake to just pick up the C-files generated by VMMaker, so that adding a new platform does not need to change the VMMaker…
But if the community is positive to just move to the Pharo way of building VMs, I'd be fine with that, since that would unify a lot of infrastructure :)
Best -Tobias
[1] https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake
On 7 November 2013 08:58, Tobias Pape Das.Linux@gmx.de wrote:
Hey Tim and all, On 07.11.2013, at 05:00, Ron Teitelbaum ron@usmedrec.com wrote:
Hey Tim,
Göran and Eliot have been discussing this. I just talked to Eliot about
it
yesterday. He said he was happy to support cmake but didn't want to
have to
do the work himself. I'm hoping that the work Göran is doing on this now can be turned over to Eliot when it is finished. I think there is
agreement
that combining the excellent work of pharo build with Eliot's new vm
work is
a very good thing to do. The work to merge the build environments is already being done at 3D ICC. We are working on this for the Mac also
but
have not discussed it with Ian yet.
Ron Teitelbaum
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of tim Rowledge Sent: Wednesday, November 06, 2013 9:04 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build
process
Wow, no interest? Is it because make is painful or because nobody needs
to
make any more money?
I actually have interest but I am currently reluctant, for time-capturing reasons in my personal and work life.
However, Here is what I would do:
• Start from Ians CMake work, and try to generalize it for the non-Linux platforms • Windows would be kind-of straight-forward, • For OS X, I would really want to have the Cocoa-based VM stuff (aka Squeak VM 5.4.7.x) integrated and proper Xcode files generated, especially to be able to have iOS VMs built automatically. Here, some information from John McIntosh would be helpfull, especially a simple walk-through. I have some experience with that[1]
Despite all admiration I have for the way the PharoVM is built, there is one thing that bothers me: • You first somehow generate the VM sources (which is fine, and the automated way is amazing) • THEN, the a Script generates CMake-Files • CMake then generates Makefiles • and then finally a vm is compiled. This is one generating step too much, for my taste. Personally, I'd prefer CMake to just pick up the C-files generated by VMMaker, so that adding a new platform does not need to change the VMMaker…
The main big issue with 'platform-neutral' static source files, that they tend to grow with tons of #ifdef-s over time, reducing readability and creating a mess.
My point is that one or another way you have to deal with platform differences, and the way how i prefer to do it is using smalltalk code, but not .m4 files, or .cmake files, or writing a medium novel long configuration files using strange (better to say weird) scripting DSL. I can express all build process logic in smalltalk, which does not lessens the amount of work to deal with all platform nuances and dependencies etc, but at least it allows me to organize and shape it into some manageable form, which is easy to change & learn.
And another difference is, that i prefer working with browser & classes than with dozens of directories and files lying here and there.
But sure thing, it is a question of taste. If you prefer to maintain this: ------------------------- MACRO (INTERNAL_PLUGIN plugin) SET (plugin_sources "") IF (DEFINED ${plugin}_sources) SET (plugin_sources ${${plugin}_sources}) ELSE (DEFINED ${plugin}_sources) FOREACH (dir ${src}/vm/intplugins ${cross}/plugins ${unix}/plugins) SET (tmp "") AUX_SOURCE_DIRECTORY (${dir}/${plugin} tmp) STRING_APPEND (plugin_sources "${tmp}") ENDFOREACH (dir) ENDIF (DEFINED ${plugin}_sources) IF (DEFINED ${plugin}_extra_sources) STRING_APPEND (plugin_sources "${${plugin}_extra_sources}") ENDIF (DEFINED ${plugin}_extra_sources) FILE (WRITE ${bld}/${plugin}/CMakeLists.in "") FOREACH (dir ${unix}/plugins ${unix}) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${dir}/${plugin}/build.cmake) ENDFOREACH (dir) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${config}/PluginInternal.cmake) CONFIGURE_FILE (${bld}/${plugin}/CMakeLists.in ${bld}/${plugin}/CMakeLists.txt @ONLY) ADD_SUBDIRECTORY (${bld}/${plugin} ${bld}/${plugin}) ENDMACRO (INTERNAL_PLUGIN) -------------------------- And/or this: -------------------------- AC_INIT([config.h.in])
SVNREV=`grep '$Rev: ' ${srcdir}/../../../platforms/Cross/vm/sqSCCSVersion.h \ | sed 's/.*$Rev: ([[0-9]][[0-9]]*).*/\1/'` AC_VM_VERSION(4,0,${SVNREV},4,2,0)
topdir=`cd ${srcdir}/../../..; pwd` cfgdir=`cd ${srcdir}; pwd`
AC_ARG_WITH(src, [ --with-src=dir generated src directory [default=src]], [ vmmsrc="${with_src}"], [ vmmsrc="src"])
vmmdir="${topdir}/${vmmsrc}"
if test ! -d "${topdir}/${vmmsrc}"; then if test -d "${topdir}/platforms/unix/${vmmsrc}"; then vmmdir="${topdir}/platforms/unix/${vmmsrc}" AC_MSG_RESULT([using built-in src directory]) fi fi
AC_MSG_RESULT(${vmmdir})
blddir=`pwd`
AC_ARG_WITH(vmmcfg, [ --with-vmmcfg=dir vm configuration directory containing plugins.int and plugins.ext [default=.]], [ vmmcfg="${with-vmmcfg}"], [ vmmcfg="${blddir}"])
# Compiling a Cogit VM or not? If so, need a cogit$o, cointerp, etc.
AC_ARG_ENABLE(cogit, [ --enable-cogit compile a cogit VM [default=yes]], cogit="no", cogit="yes") AC_SUBST(cogit)
#AC_ARG_ENABLE(jit, #[ --enable-jit enable J4 support [default=no]], #JIT="yes", JIT="no") # #test $JIT = "yes" && J_CFLAGS="-DJ_ENABLED" #AC_SUBST(J_CFLAGS)
# Check the generated src dir looks sane
AC_CHECK_VMM_DIR
AC_SUBST(topdir) AC_SUBST(cfgdir) AC_SUBST(vmmdir) AC_SUBST(vmmcfg) AC_SUBST(blddir)
SQ_VERSION=${SQ_MAJOR}.${SQ_MINOR}-${SQ_UPDATE}
AC_DEFINE_UNQUOTED(SQ_VERSION, "${SQ_VERSION}")
AC_SUBST(SQ_MAJOR) AC_SUBST(SQ_MINOR) AC_SUBST(SQ_UPDATE) AC_SUBST(SQ_VERSION)
VM_VERSION=${VM_MAJOR}.${VM_MINOR}-${VM_RELEASE}
AC_DEFINE_UNQUOTED(VM_VERSION, "${VM_VERSION}")
AC_SUBST(VM_MAJOR) AC_SUBST(VM_MINOR) AC_SUBST(VM_RELEASE) AC_SUBST(VM_VERSION)
# libdir contains ${exec_prefix}, so we have to default and expand early test "x$prefix" = xNONE && prefix=$ac_default_prefix test "x$exec_prefix" = xNONE && exec_prefix='${prefix}' imgdir=`eval echo ${libdir}/squeak` expanded_relative_imgdir=`eval echo lib/squeak/${VM_VERSION}` plgdir='${imgdir}/'`eval echo ${VM_VERSION}`
AC_SUBST(imgdir) AC_SUBST(expanded_relative_imgdir) AC_SUBST(plgdir)
AC_DEFINE(OS_TYPE, "unix")
AC_CANONICAL_HOST
host_cpu=`echo $host | sed 's,-.*,,'` host=`echo $host | sed 's,-unknown,,'`
AC_SUBST(host) AC_SUBST(host_cpu) AC_SUBST(host_vendor) AC_SUBST(host_os) ----------------------------
instead of plain smalltalk code, it is up to you.
But that's about 'too much' for my taste.
But if the community is positive to just move to the Pharo way of
building VMs, I'd be fine with that, since that would unify a lot of infrastructure :)
Best -Tobias
[1] https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake
It's absolutely none of my business what tools others choose to use, but I will say this:
Having more of this process in Smalltalk and less in other (arcane) languages increases the confidence that, should we lose someone's services, others could step up to fill the gap.
Cheers, Bob
On 11/7/13 8:28 AM, Igor Stasenko wrote:
On 7 November 2013 08:58, Tobias Pape <Das.Linux@gmx.de mailto:Das.Linux@gmx.de> wrote:
Hey Tim and all, On 07.11.2013, at 05:00, Ron Teitelbaum <ron@usmedrec.com <mailto:ron@usmedrec.com>> wrote: > Hey Tim, > > Göran and Eliot have been discussing this. I just talked to Eliot about it > yesterday. He said he was happy to support cmake but didn't want to have to > do the work himself. I'm hoping that the work Göran is doing on this now > can be turned over to Eliot when it is finished. I think there is agreement > that combining the excellent work of pharo build with Eliot's new vm work is > a very good thing to do. The work to merge the build environments is > already being done at 3D ICC. We are working on this for the Mac also but > have not discussed it with Ian yet. > > Ron Teitelbaum > >> -----Original Message----- >> From: squeak-dev-bounces@lists.squeakfoundation.org <mailto:squeak-dev-bounces@lists.squeakfoundation.org> [mailto:squeak-dev- <mailto:squeak-dev-> >> bounces@lists.squeakfoundation.org <mailto:bounces@lists.squeakfoundation.org>] On Behalf Of tim Rowledge >> Sent: Wednesday, November 06, 2013 9:04 PM >> To: The general-purpose Squeak developers list >> Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build > process >> >> >> Wow, no interest? Is it because make is painful or because nobody needs to >> make any more money? I actually have interest but I am currently reluctant, for time-capturing reasons in my personal and work life. However, Here is what I would do: . Start from Ians CMake work, and try to generalize it for the non-Linux platforms . Windows would be kind-of straight-forward, . For OS X, I would really want to have the Cocoa-based VM stuff (aka Squeak VM 5.4.7.x) integrated and proper Xcode files generated, especially to be able to have iOS VMs built automatically. Here, some information from John McIntosh would be helpfull, especially a simple walk-through. I have some experience with that[1] Despite all admiration I have for the way the PharoVM is built, there is one thing that bothers me: . You first somehow generate the VM sources (which is fine, and the automated way is amazing) . THEN, the a Script generates CMake-Files . CMake then generates Makefiles . and then finally a vm is compiled. This is one generating step too much, for my taste. Personally, I'd prefer CMake to just pick up the C-files generated by VMMaker, so that adding a new platform does not need to change the VMMaker...The main big issue with 'platform-neutral' static source files, that they tend to grow with tons of #ifdef-s over time, reducing readability and creating a mess.
My point is that one or another way you have to deal with platform differences, and the way how i prefer to do it is using smalltalk code, but not .m4 files, or .cmake files, or writing a medium novel long configuration files using strange (better to say weird) scripting DSL. I can express all build process logic in smalltalk, which does not lessens the amount of work to deal with all platform nuances and dependencies etc, but at least it allows me to organize and shape it into some manageable form, which is easy to change & learn.
And another difference is, that i prefer working with browser & classes than with dozens of directories and files lying here and there.
But sure thing, it is a question of taste. If you prefer to maintain this:
MACRO (INTERNAL_PLUGIN plugin) SET (plugin_sources "") IF (DEFINED ${plugin}_sources) SET (plugin_sources ${${plugin}_sources}) ELSE (DEFINED ${plugin}_sources) FOREACH (dir ${src}/vm/intplugins ${cross}/plugins ${unix}/plugins) SET (tmp "") AUX_SOURCE_DIRECTORY (${dir}/${plugin} tmp) STRING_APPEND (plugin_sources "${tmp}") ENDFOREACH (dir) ENDIF (DEFINED ${plugin}_sources) IF (DEFINED ${plugin}_extra_sources) STRING_APPEND (plugin_sources "${${plugin}_extra_sources}") ENDIF (DEFINED ${plugin}_extra_sources) FILE (WRITE ${bld}/${plugin}/CMakeLists.in "") FOREACH (dir ${unix}/plugins ${unix}) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${dir}/${plugin}/build.cmake) ENDFOREACH (dir) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${config}/PluginInternal.cmake) CONFIGURE_FILE (${bld}/${plugin}/CMakeLists.in ${bld}/${plugin}/CMakeLists.txt @ONLY) ADD_SUBDIRECTORY (${bld}/${plugin} ${bld}/${plugin}) ENDMACRO (INTERNAL_PLUGIN)
And/or this:
AC_INIT([config.h.in http://config.h.in])
SVNREV=`grep '$Rev: ' ${srcdir}/../../../platforms/Cross/vm/sqSCCSVersion.h \ | sed 's/.*$Rev: ([[0-9]][[0-9]]*).*/\1/'` AC_VM_VERSION(4,0,${SVNREV},4,2,0)
topdir=`cd ${srcdir}/../../..; pwd` cfgdir=`cd ${srcdir}; pwd`
AC_ARG_WITH(src, [ --with-src=dir generated src directory [default=src]], [ vmmsrc="${with_src}"], [ vmmsrc="src"])
vmmdir="${topdir}/${vmmsrc}"
if test ! -d "${topdir}/${vmmsrc}"; then if test -d "${topdir}/platforms/unix/${vmmsrc}"; then vmmdir="${topdir}/platforms/unix/${vmmsrc}" AC_MSG_RESULT([using built-in src directory]) fi fi
AC_MSG_RESULT(${vmmdir})
blddir=`pwd`
AC_ARG_WITH(vmmcfg, [ --with-vmmcfg=dir vm configuration directory containing plugins.int http://plugins.int and plugins.ext [default=.]], [ vmmcfg="${with-vmmcfg}"], [ vmmcfg="${blddir}"])
# Compiling a Cogit VM or not? If so, need a cogit$o, cointerp, etc.
AC_ARG_ENABLE(cogit, [ --enable-cogit compile a cogit VM [default=yes]], cogit="no", cogit="yes") AC_SUBST(cogit)
#AC_ARG_ENABLE(jit, #[ --enable-jit enable J4 support [default=no]], #JIT="yes", JIT="no") # #test $JIT = "yes" && J_CFLAGS="-DJ_ENABLED" #AC_SUBST(J_CFLAGS)
# Check the generated src dir looks sane
AC_CHECK_VMM_DIR
AC_SUBST(topdir) AC_SUBST(cfgdir) AC_SUBST(vmmdir) AC_SUBST(vmmcfg) AC_SUBST(blddir)
SQ_VERSION=${SQ_MAJOR}.${SQ_MINOR}-${SQ_UPDATE}
AC_DEFINE_UNQUOTED(SQ_VERSION, "${SQ_VERSION}")
AC_SUBST(SQ_MAJOR) AC_SUBST(SQ_MINOR) AC_SUBST(SQ_UPDATE) AC_SUBST(SQ_VERSION)
VM_VERSION=${VM_MAJOR}.${VM_MINOR}-${VM_RELEASE}
AC_DEFINE_UNQUOTED(VM_VERSION, "${VM_VERSION}")
AC_SUBST(VM_MAJOR) AC_SUBST(VM_MINOR) AC_SUBST(VM_RELEASE) AC_SUBST(VM_VERSION)
# libdir contains ${exec_prefix}, so we have to default and expand early test "x$prefix" = xNONE && prefix=$ac_default_prefix test "x$exec_prefix" = xNONE && exec_prefix='${prefix}' imgdir=`eval echo ${libdir}/squeak` expanded_relative_imgdir=`eval echo lib/squeak/${VM_VERSION}` plgdir='${imgdir}/'`eval echo ${VM_VERSION}`
AC_SUBST(imgdir) AC_SUBST(expanded_relative_imgdir) AC_SUBST(plgdir)
AC_DEFINE(OS_TYPE, "unix")
AC_CANONICAL_HOST
host_cpu=`echo $host | sed 's,-.*,,'` host=`echo $host | sed 's,-unknown,,'`
AC_SUBST(host) AC_SUBST(host_cpu) AC_SUBST(host_vendor) AC_SUBST(host_os)
instead of plain smalltalk code, it is up to you.
But that's about 'too much' for my taste.
But if the community is positive to just move to the Pharo way of building VMs, I'd be fine with that, since that would unify a lot of infrastructure :) Best -Tobias [1] https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake-- Best regards, Igor Stasenko.
Btw, speaking about too long generation chain.
automake: - you modify .ac file(s) - you run autoconfig to generate configure script - you run configure script to generate makefiles - you run build
with cmakevmmaker:
- you modify build config in one of the class(es) in smalltalk code - you run it to generate VM configs & VM sources (.c/.h/.cmake files) - you run cmake - and finally build
And there's a good potential for even more automation: by using OSProcess and building whole VM from an image, which means a single do-it to build VM, and then run tests if build passes, run benchmarks, bring results on screen or store them somewhere and/or upload artifacts into proper place etc etc.
And now imagine how you would manage to do that using command line tools, like sed, awk, curl, shell scripts, perl, python, makefiles, autoconf & anything else which you wanna throw into the soup to make it more fun.
On 7 November 2013 15:01, Bob Arning arning315@comcast.net wrote:
It's absolutely none of my business what tools others choose to use, but I will say this:
Having more of this process in Smalltalk and less in other (arcane) languages increases the confidence that, should we lose someone's services, others could step up to fill the gap.
Cheers, Bob
On 11/7/13 8:28 AM, Igor Stasenko wrote:
On 7 November 2013 08:58, Tobias Pape Das.Linux@gmx.de wrote:
Hey Tim and all, On 07.11.2013, at 05:00, Ron Teitelbaum ron@usmedrec.com wrote:
Hey Tim,
Göran and Eliot have been discussing this. I just talked to Eliot
about it
yesterday. He said he was happy to support cmake but didn't want to
have to
do the work himself. I'm hoping that the work Göran is doing on this
now
can be turned over to Eliot when it is finished. I think there is
agreement
that combining the excellent work of pharo build with Eliot's new vm
work is
a very good thing to do. The work to merge the build environments is already being done at 3D ICC. We are working on this for the Mac also
but
have not discussed it with Ian yet.
Ron Teitelbaum
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:
squeak-dev-
bounces@lists.squeakfoundation.org] On Behalf Of tim Rowledge Sent: Wednesday, November 06, 2013 9:04 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build
process
Wow, no interest? Is it because make is painful or because nobody
needs to
make any more money?
I actually have interest but I am currently reluctant, for time-capturing reasons in my personal and work life.
However, Here is what I would do:
• Start from Ians CMake work, and try to generalize it for the non-Linux platforms • Windows would be kind-of straight-forward, • For OS X, I would really want to have the Cocoa-based VM stuff (aka Squeak VM 5.4.7.x) integrated and proper Xcode files generated, especially to be able to have iOS VMs built automatically. Here, some information from John McIntosh would be helpfull, especially a simple walk-through. I have some experience with that[1]
Despite all admiration I have for the way the PharoVM is built, there is one thing that bothers me: • You first somehow generate the VM sources (which is fine, and the automated way is amazing) • THEN, the a Script generates CMake-Files • CMake then generates Makefiles • and then finally a vm is compiled. This is one generating step too much, for my taste. Personally, I'd prefer CMake to just pick up the C-files generated by VMMaker, so that adding a new platform does not need to change the VMMaker…
The main big issue with 'platform-neutral' static source files, that they tend to grow with tons of #ifdef-s over time, reducing readability and creating a mess.
My point is that one or another way you have to deal with platform differences, and the way how i prefer to do it is using smalltalk code, but not .m4 files, or .cmake files, or writing a medium novel long configuration files using strange (better to say weird) scripting DSL. I can express all build process logic in smalltalk, which does not lessens the amount of work to deal with all platform nuances and dependencies etc, but at least it allows me to organize and shape it into some manageable form, which is easy to change & learn.
And another difference is, that i prefer working with browser & classes than with dozens of directories and files lying here and there.
But sure thing, it is a question of taste. If you prefer to maintain this:
MACRO (INTERNAL_PLUGIN plugin) SET (plugin_sources "") IF (DEFINED ${plugin}_sources) SET (plugin_sources ${${plugin}_sources}) ELSE (DEFINED ${plugin}_sources) FOREACH (dir ${src}/vm/intplugins ${cross}/plugins ${unix}/plugins) SET (tmp "") AUX_SOURCE_DIRECTORY (${dir}/${plugin} tmp) STRING_APPEND (plugin_sources "${tmp}") ENDFOREACH (dir) ENDIF (DEFINED ${plugin}_sources) IF (DEFINED ${plugin}_extra_sources) STRING_APPEND (plugin_sources "${${plugin}_extra_sources}") ENDIF (DEFINED ${plugin}_extra_sources) FILE (WRITE ${bld}/${plugin}/CMakeLists.in "") FOREACH (dir ${unix}/plugins ${unix}) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${dir}/${plugin}/build.cmake) ENDFOREACH (dir) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${config}/PluginInternal.cmake) CONFIGURE_FILE (${bld}/${plugin}/CMakeLists.in ${bld}/${plugin}/CMakeLists.txt @ONLY) ADD_SUBDIRECTORY (${bld}/${plugin} ${bld}/${plugin}) ENDMACRO (INTERNAL_PLUGIN)
And/or this:
AC_INIT([config.h.in])
SVNREV=`grep '$Rev: ' ${srcdir}/../../../platforms/Cross/vm/sqSCCSVersion.h \ | sed 's/.*$Rev: ([[0-9]][[0-9]]*).*/\1/'` AC_VM_VERSION(4,0,${SVNREV},4,2,0)
topdir=`cd ${srcdir}/../../..; pwd` cfgdir=`cd ${srcdir}; pwd`
AC_ARG_WITH(src, [ --with-src=dir generated src directory [default=src]], [ vmmsrc="${with_src}"], [ vmmsrc="src"])
vmmdir="${topdir}/${vmmsrc}"
if test ! -d "${topdir}/${vmmsrc}"; then if test -d "${topdir}/platforms/unix/${vmmsrc}"; then vmmdir="${topdir}/platforms/unix/${vmmsrc}" AC_MSG_RESULT([using built-in src directory]) fi fi
AC_MSG_RESULT(${vmmdir})
blddir=`pwd`
AC_ARG_WITH(vmmcfg, [ --with-vmmcfg=dir vm configuration directory containing plugins.int and plugins.ext [default=.]], [ vmmcfg="${with-vmmcfg}"], [ vmmcfg="${blddir}"])
# Compiling a Cogit VM or not? If so, need a cogit$o, cointerp, etc.
AC_ARG_ENABLE(cogit, [ --enable-cogit compile a cogit VM [default=yes]], cogit="no", cogit="yes") AC_SUBST(cogit)
#AC_ARG_ENABLE(jit, #[ --enable-jit enable J4 support [default=no]], #JIT="yes", JIT="no") # #test $JIT = "yes" && J_CFLAGS="-DJ_ENABLED" #AC_SUBST(J_CFLAGS)
# Check the generated src dir looks sane
AC_CHECK_VMM_DIR
AC_SUBST(topdir) AC_SUBST(cfgdir) AC_SUBST(vmmdir) AC_SUBST(vmmcfg) AC_SUBST(blddir)
SQ_VERSION=${SQ_MAJOR}.${SQ_MINOR}-${SQ_UPDATE}
AC_DEFINE_UNQUOTED(SQ_VERSION, "${SQ_VERSION}")
AC_SUBST(SQ_MAJOR) AC_SUBST(SQ_MINOR) AC_SUBST(SQ_UPDATE) AC_SUBST(SQ_VERSION)
VM_VERSION=${VM_MAJOR}.${VM_MINOR}-${VM_RELEASE}
AC_DEFINE_UNQUOTED(VM_VERSION, "${VM_VERSION}")
AC_SUBST(VM_MAJOR) AC_SUBST(VM_MINOR) AC_SUBST(VM_RELEASE) AC_SUBST(VM_VERSION)
# libdir contains ${exec_prefix}, so we have to default and expand early test "x$prefix" = xNONE && prefix=$ac_default_prefix test "x$exec_prefix" = xNONE && exec_prefix='${prefix}' imgdir=`eval echo ${libdir}/squeak` expanded_relative_imgdir=`eval echo lib/squeak/${VM_VERSION}` plgdir='${imgdir}/'`eval echo ${VM_VERSION}`
AC_SUBST(imgdir) AC_SUBST(expanded_relative_imgdir) AC_SUBST(plgdir)
AC_DEFINE(OS_TYPE, "unix")
AC_CANONICAL_HOST
host_cpu=`echo $host | sed 's,-.*,,'` host=`echo $host | sed 's,-unknown,,'`
AC_SUBST(host) AC_SUBST(host_cpu) AC_SUBST(host_vendor) AC_SUBST(host_os)
instead of plain smalltalk code, it is up to you.
But that's about 'too much' for my taste.
But if the community is positive to just move to the Pharo way of
building VMs, I'd be fine with that, since that would unify a lot of infrastructure :)
Best -Tobias
[1] https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake
-- Best regards, Igor Stasenko.
Is there any chance Cog could be made to run on AMD64 natively without 32 bit libs?
If so, I would like to help out with whoever takes up this task. I would need direction, however as I have been do app development for too many years and my sys skills are atrophied.
t.
---- On Thu, 07 Nov 2013 06:01:00 -0800 Bob Arning<arning315@comcast.net> wrote ----
It's absolutely none of my business what tools others choose to use, but I will say this:
Having more of this process in Smalltalk and less in other (arcane) languages increases the confidence that, should we lose someone's services, others could step up to fill the gap.
Cheers, Bob
On 11/7/13 8:28 AM, Igor Stasenko wrote:
Ec7Xf8-DaANjijv1beYiqxBApPntNg@mail.gmail.com" type="cite">
On 7 November 2013 08:58, Tobias Pape <Das.Linux@gmx.de> wrote: Hey Tim and all, On 07.11.2013, at 05:00, Ron Teitelbaum <ron@usmedrec.com> wrote:
> Hey Tim, > > Göran and Eliot have been discussing this. I just talked to Eliot about it > yesterday. He said he was happy to support cmake but didn't want to have to > do the work himself. I'm hoping that the work Göran is doing on this now > can be turned over to Eliot when it is finished. I think there is agreement > that combining the excellent work of pharo build with Eliot's new vm work is > a very good thing to do. The work to merge the build environments is > already being done at 3D ICC. We are working on this for the Mac also but > have not discussed it with Ian yet. > > Ron Teitelbaum > >> -----Original Message----- >> From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- >> bounces@lists.squeakfoundation.org] On Behalf Of tim Rowledge >> Sent: Wednesday, November 06, 2013 9:04 PM >> To: The general-purpose Squeak developers list >> Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build > process >> >> >> Wow, no interest? Is it because make is painful or because nobody needs to >> make any more money?
I actually have interest but I am currently reluctant, for time-capturing reasons in my personal and work life.
However, Here is what I would do:
• Start from Ians CMake work, and try to generalize it for the non-Linux platforms • Windows would be kind-of straight-forward, • For OS X, I would really want to have the Cocoa-based VM stuff (aka Squeak VM 5.4.7.x) integrated and proper Xcode files generated, especially to be able to have iOS VMs built automatically. Here, some information from John McIntosh would be helpfull, especially a simple walk-through. I have some experience with that[1]
Despite all admiration I have for the way the PharoVM is built, there is one thing that bothers me: • You first somehow generate the VM sources (which is fine, and the automated way is amazing) • THEN, the a Script generates CMake-Files • CMake then generates Makefiles • and then finally a vm is compiled. This is one generating step too much, for my taste. Personally, I'd prefer CMake to just pick up the C-files generated by VMMaker, so that adding a new platform does not need to change the VMMaker…
The main big issue with 'platform-neutral' static source files, that they tend to
grow with tons of #ifdef-s over time, reducing readability and creating a mess.
My point is that one or another way you have to deal with platform differences,
and the way how i prefer to do it is using smalltalk code,
but not .m4 files, or .cmake files, or writing a medium novel long configuration files
using strange (better to say weird) scripting DSL.
I can express all build process logic in smalltalk, which does not lessens the amount of work to deal with all platform nuances and dependencies etc, but at least it allows me to organize and shape it into some manageable form, which is easy to change & learn.
And another difference is, that i prefer working with browser & classes than with dozens of directories and files lying here and there.
But sure thing, it is a question of taste. If you prefer to maintain this: ------------------------- MACRO (INTERNAL_PLUGIN plugin) SET (plugin_sources "") IF (DEFINED ${plugin}_sources) SET (plugin_sources ${${plugin}_sources}) ELSE (DEFINED ${plugin}_sources) FOREACH (dir ${src}/vm/intplugins ${cross}/plugins ${unix}/plugins) SET (tmp "") AUX_SOURCE_DIRECTORY (${dir}/${plugin} tmp) STRING_APPEND (plugin_sources "${tmp}") ENDFOREACH (dir) ENDIF (DEFINED ${plugin}_sources) IF (DEFINED ${plugin}_extra_sources) STRING_APPEND (plugin_sources "${${plugin}_extra_sources}") ENDIF (DEFINED ${plugin}_extra_sources) FILE (WRITE ${bld}/${plugin}/CMakeLists.in "") FOREACH (dir ${unix}/plugins ${unix}) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${dir}/${plugin}/build.cmake) ENDFOREACH (dir) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${config}/PluginInternal.cmake) CONFIGURE_FILE (${bld}/${plugin}/CMakeLists.in ${bld}/${plugin}/CMakeLists.txt @ONLY) ADD_SUBDIRECTORY (${bld}/${plugin} ${bld}/${plugin}) ENDMACRO (INTERNAL_PLUGIN) --------------------------
And/or this: -------------------------- AC_INIT([config.h.in])
SVNREV=`grep '$Rev: ' ${srcdir}/../../../platforms/Cross/vm/sqSCCSVersion.h \ | sed 's/.*$Rev: ([[0-9]][[0-9]]*).*/\1/'` AC_VM_VERSION(4,0,${SVNREV},4,2,0)
topdir=`cd ${srcdir}/../../..; pwd` cfgdir=`cd ${srcdir}; pwd`
AC_ARG_WITH(src, [ --with-src=dir generated src directory [default=src]], [ vmmsrc="${with_src}"], [ vmmsrc="src"])
vmmdir="${topdir}/${vmmsrc}"
if test ! -d "${topdir}/${vmmsrc}"; then if test -d "${topdir}/platforms/unix/${vmmsrc}"; then vmmdir="${topdir}/platforms/unix/${vmmsrc}" AC_MSG_RESULT([using built-in src directory]) fi fi
AC_MSG_RESULT(${vmmdir})
blddir=`pwd`
AC_ARG_WITH(vmmcfg, [ --with-vmmcfg=dir vm configuration directory containing plugins.int and plugins.ext [default=.]], [ vmmcfg="${with-vmmcfg}"], [ vmmcfg="${blddir}"])
# Compiling a Cogit VM or not? If so, need a cogit$o, cointerp, etc.
AC_ARG_ENABLE(cogit, [ --enable-cogit compile a cogit VM [default=yes]], cogit="no", cogit="yes") AC_SUBST(cogit)
#AC_ARG_ENABLE(jit, #[ --enable-jit enable J4 support [default=no]], #JIT="yes", JIT="no") # #test $JIT = "yes" && J_CFLAGS="-DJ_ENABLED" #AC_SUBST(J_CFLAGS)
# Check the generated src dir looks sane
AC_CHECK_VMM_DIR
AC_SUBST(topdir) AC_SUBST(cfgdir) AC_SUBST(vmmdir) AC_SUBST(vmmcfg) AC_SUBST(blddir)
SQ_VERSION=${SQ_MAJOR}.${SQ_MINOR}-${SQ_UPDATE}
AC_DEFINE_UNQUOTED(SQ_VERSION, "${SQ_VERSION}")
AC_SUBST(SQ_MAJOR) AC_SUBST(SQ_MINOR) AC_SUBST(SQ_UPDATE) AC_SUBST(SQ_VERSION)
VM_VERSION=${VM_MAJOR}.${VM_MINOR}-${VM_RELEASE}
AC_DEFINE_UNQUOTED(VM_VERSION, "${VM_VERSION}")
AC_SUBST(VM_MAJOR) AC_SUBST(VM_MINOR) AC_SUBST(VM_RELEASE) AC_SUBST(VM_VERSION)
# libdir contains ${exec_prefix}, so we have to default and expand early test "x$prefix" = xNONE && prefix=$ac_default_prefix test "x$exec_prefix" = xNONE && exec_prefix='${prefix}' imgdir=`eval echo ${libdir}/squeak` expanded_relative_imgdir=`eval echo lib/squeak/${VM_VERSION}` plgdir='${imgdir}/'`eval echo ${VM_VERSION}`
AC_SUBST(imgdir) AC_SUBST(expanded_relative_imgdir) AC_SUBST(plgdir)
AC_DEFINE(OS_TYPE, "unix")
AC_CANONICAL_HOST
host_cpu=`echo $host | sed 's,-.*,,'` host=`echo $host | sed 's,-unknown,,'`
AC_SUBST(host) AC_SUBST(host_cpu) AC_SUBST(host_vendor) AC_SUBST(host_os) ----------------------------
instead of plain smalltalk code, it is up to you.
But that's about 'too much' for my taste.
But if the community is positive to just move to the Pharo way of building VMs, I'd be fine with that, since that would unify a lot of infrastructure :)
Best -Tobias
[1] https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake
-- Best regards, Igor Stasenko.
Hi Timothy,
On Thu, Nov 7, 2013 at 7:02 AM, gettimothy gettimothy@zoho.com wrote:
Is there any chance Cog could be made to run on AMD64 natively without 32 bit libs?
Yes, that's a goal of my current work. Spur has a common object representation between 32- and 64-bits. Getting to a native Stack VM on AMD64 should be straight-forward. Getting to a Cog VM on AMD64 also requires writing a code generator for AMD64. That's actually a fun project. It involves configuring a Bochs plugin for an AMD64/IA32 simulator, and then writing a CogIA64Compiler subclass of CogAbstractInstruction.
If so, I would like to help out with whoever takes up this task. I would need direction, however as I have been do app development for too many years and my sys skills are atrophied.
How strong are your low-level skills? You'll need to be quite familiar with machine code, basic machine organization, etc. If you're not then you could instead have a go at getting the Stack VM working in 64-bits, and that would involve getting the 64-bit VM simulator working in VMMaker.
It will be great to have another collaborator!
t.
---- On Thu, 07 Nov 2013 06:01:00 -0800 *Bob Arning<arning315@comcast.net arning315@comcast.net>* wrote ----
It's absolutely none of my business what tools others choose to use, but I will say this:
Having more of this process in Smalltalk and less in other (arcane) languages increases the confidence that, should we lose someone's services, others could step up to fill the gap.
Cheers, Bob
On 11/7/13 8:28 AM, Igor Stasenko wrote:
Ec7Xf8-DaANjijv1beYiqxBApPntNg@mail.gmail.com" type="cite">
On 7 November 2013 08:58, Tobias Pape Das.Linux@gmx.de wrote:
Hey Tim and all, On 07.11.2013, at 05:00, Ron Teitelbaum ron@usmedrec.com wrote:
Hey Tim,
Göran and Eliot have been discussing this. I just talked to Eliot about
it
yesterday. He said he was happy to support cmake but didn't want to
have to
do the work himself. I'm hoping that the work Göran is doing on this now can be turned over to Eliot when it is finished. I think there is
agreement
that combining the excellent work of pharo build with Eliot's new vm
work is
a very good thing to do. The work to merge the build environments is already being done at 3D ICC. We are working on this for the Mac also
but
have not discussed it with Ian yet.
Ron Teitelbaum
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of tim Rowledge Sent: Wednesday, November 06, 2013 9:04 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build
process
Wow, no interest? Is it because make is painful or because nobody needs
to
make any more money?
I actually have interest but I am currently reluctant, for time-capturing reasons in my personal and work life.
However, Here is what I would do:
• Start from Ians CMake work, and try to generalize it for the non-Linux platforms • Windows would be kind-of straight-forward, • For OS X, I would really want to have the Cocoa-based VM stuff (aka Squeak VM 5.4.7.x) integrated and proper Xcode files generated, especially to be able to have iOS VMs built automatically. Here, some information from John McIntosh would be helpfull, especially a simple walk-through. I have some experience with that[1]
Despite all admiration I have for the way the PharoVM is built, there is one thing that bothers me: • You first somehow generate the VM sources (which is fine, and the automated way is amazing) • THEN, the a Script generates CMake-Files • CMake then generates Makefiles • and then finally a vm is compiled. This is one generating step too much, for my taste. Personally, I'd prefer CMake to just pick up the C-files generated by VMMaker, so that adding a new platform does not need to change the VMMaker…
The main big issue with 'platform-neutral' static source files, that they tend to grow with tons of #ifdef-s over time, reducing readability and creating a mess.
My point is that one or another way you have to deal with platform differences, and the way how i prefer to do it is using smalltalk code, but not .m4 files, or .cmake files, or writing a medium novel long configuration files using strange (better to say weird) scripting DSL. I can express all build process logic in smalltalk, which does not lessens the amount of work to deal with all platform nuances and dependencies etc, but at least it allows me to organize and shape it into some manageable form, which is easy to change & learn.
And another difference is, that i prefer working with browser & classes than with dozens of directories and files lying here and there.
But sure thing, it is a question of taste. If you prefer to maintain this:
MACRO (INTERNAL_PLUGIN plugin) SET (plugin_sources "") IF (DEFINED ${plugin}_sources) SET (plugin_sources ${${plugin}_sources}) ELSE (DEFINED ${plugin}_sources) FOREACH (dir ${src}/vm/intplugins ${cross}/plugins ${unix}/plugins) SET (tmp "") AUX_SOURCE_DIRECTORY (${dir}/${plugin} tmp) STRING_APPEND (plugin_sources "${tmp}") ENDFOREACH (dir) ENDIF (DEFINED ${plugin}_sources) IF (DEFINED ${plugin}_extra_sources) STRING_APPEND (plugin_sources "${${plugin}_extra_sources}") ENDIF (DEFINED ${plugin}_extra_sources) FILE (WRITE ${bld}/${plugin}/CMakeLists.in "") FOREACH (dir ${unix}/plugins ${unix}) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${dir}/${plugin}/build.cmake) ENDFOREACH (dir) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${config}/PluginInternal.cmake) CONFIGURE_FILE (${bld}/${plugin}/CMakeLists.in ${bld}/${plugin}/CMakeLists.txt @ONLY) ADD_SUBDIRECTORY (${bld}/${plugin} ${bld}/${plugin}) ENDMACRO (INTERNAL_PLUGIN)
And/or this:
AC_INIT([config.h.in])
SVNREV=`grep '$Rev: ' ${srcdir}/../../../platforms/Cross/vm/sqSCCSVersion.h \ | sed 's/.*$Rev: ([[0-9]][[0-9]]*).*/\1/'` AC_VM_VERSION(4,0,${SVNREV},4,2,0)
topdir=`cd ${srcdir}/../../..; pwd` cfgdir=`cd ${srcdir}; pwd`
AC_ARG_WITH(src, [ --with-src=dir generated src directory [default=src]], [ vmmsrc="${with_src}"], [ vmmsrc="src"])
vmmdir="${topdir}/${vmmsrc}"
if test ! -d "${topdir}/${vmmsrc}"; then if test -d "${topdir}/platforms/unix/${vmmsrc}"; then vmmdir="${topdir}/platforms/unix/${vmmsrc}" AC_MSG_RESULT([using built-in src directory]) fi fi
AC_MSG_RESULT(${vmmdir})
blddir=`pwd`
AC_ARG_WITH(vmmcfg, [ --with-vmmcfg=dir vm configuration directory containing plugins.int and plugins.ext [default=.]], [ vmmcfg="${with-vmmcfg}"], [ vmmcfg="${blddir}"])
# Compiling a Cogit VM or not? If so, need a cogit$o, cointerp, etc.
AC_ARG_ENABLE(cogit, [ --enable-cogit compile a cogit VM [default=yes]], cogit="no", cogit="yes") AC_SUBST(cogit)
#AC_ARG_ENABLE(jit, #[ --enable-jit enable J4 support [default=no]], #JIT="yes", JIT="no") # #test $JIT = "yes" && J_CFLAGS="-DJ_ENABLED" #AC_SUBST(J_CFLAGS)
# Check the generated src dir looks sane
AC_CHECK_VMM_DIR
AC_SUBST(topdir) AC_SUBST(cfgdir) AC_SUBST(vmmdir) AC_SUBST(vmmcfg) AC_SUBST(blddir)
SQ_VERSION=${SQ_MAJOR}.${SQ_MINOR}-${SQ_UPDATE}
AC_DEFINE_UNQUOTED(SQ_VERSION, "${SQ_VERSION}")
AC_SUBST(SQ_MAJOR) AC_SUBST(SQ_MINOR) AC_SUBST(SQ_UPDATE) AC_SUBST(SQ_VERSION)
VM_VERSION=${VM_MAJOR}.${VM_MINOR}-${VM_RELEASE}
AC_DEFINE_UNQUOTED(VM_VERSION, "${VM_VERSION}")
AC_SUBST(VM_MAJOR) AC_SUBST(VM_MINOR) AC_SUBST(VM_RELEASE) AC_SUBST(VM_VERSION)
# libdir contains ${exec_prefix}, so we have to default and expand early test "x$prefix" = xNONE && prefix=$ac_default_prefix test "x$exec_prefix" = xNONE && exec_prefix='${prefix}' imgdir=`eval echo ${libdir}/squeak` expanded_relative_imgdir=`eval echo lib/squeak/${VM_VERSION}` plgdir='${imgdir}/'`eval echo ${VM_VERSION}`
AC_SUBST(imgdir) AC_SUBST(expanded_relative_imgdir) AC_SUBST(plgdir)
AC_DEFINE(OS_TYPE, "unix")
AC_CANONICAL_HOST
host_cpu=`echo $host | sed 's,-.*,,'` host=`echo $host | sed 's,-unknown,,'`
AC_SUBST(host) AC_SUBST(host_cpu) AC_SUBST(host_vendor) AC_SUBST(host_os)
instead of plain smalltalk code, it is up to you.
But that's about 'too much' for my taste.
But if the community is positive to just move to the Pharo way of building VMs, I'd be fine with that, since that would unify a lot of infrastructure :)
Best -Tobias
[1] https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake
-- Best regards, Igor Stasenko.
Eliot,
Thank you so much for the reply.
Currently my low-level skills are atrophied and have organized my work-life to devote study time to regaining and improving them. This is a great opportunity to contribute and get my chops up in the process.
When you refer to 'machine code' and 'machine organization' do you mean the Cog/Squeak VM's or the AMD 64 instruction set? (I lack both, but if you mean the VM, a good exercise in learning it would be writing some good documentation on it)
From your reply, I guess I would best be of use getting the Stack VM working in 64 bits--its something I am currently attempting to do.
I have a tri-boot machine--Windows 7, Linux with 32 bit compat libs--where I can run smalltalk, and a pure 64 bit boot, where I cannot run smalltalk.
I am currently attempting to get the source code from http://www.squeakvm.org/squeak64/ Squeak-3.8a-2.src.tar.gz to compile on the pure 64 box. The Quick Start steps failed, so I am now setting about studying the source code in merge64/platforms/unix/vm/sqUnixMain.c as it looks like the entry point for the VM. In the back of my mind, I am wondering if this is even the right approach to take..
What do you think is the best approach to take?
Cordially,
t
---- On Thu, 07 Nov 2013 10:54:01 -0800 Eliot Miranda<eliot.miranda@gmail.com> wrote ----
Hi Timothy,
On Thu, Nov 7, 2013 at 7:02 AM, gettimothy <gettimothy@zoho.com> wrote: Is there any chance Cog could be made to run on AMD64 natively without 32 bit libs?
Yes, that's a goal of my current work. Spur has a common object representation between 32- and 64-bits. Getting to a native Stack VM on AMD64 should be straight-forward. Getting to a Cog VM on AMD64 also requires writing a code generator for AMD64. That's actually a fun project. It involves configuring a Bochs plugin for an AMD64/IA32 simulator, and then writing a CogIA64Compiler subclass of CogAbstractInstruction.
If so, I would like to help out with whoever takes up this task. I would need direction, however as I have been do app development for too many years and my sys skills are atrophied.
How strong are your low-level skills? You'll need to be quite familiar with machine code, basic machine organization, etc. If you're not then you could instead have a go at getting the Stack VM working in 64-bits, and that would involve getting the 64-bit VM simulator working in VMMaker.
It will be great to have another collaborator!
t.
---- On Thu, 07 Nov 2013 06:01:00 -0800 Bob Arning<arning315@comcast.net> wrote ----
It's absolutely none of my business what tools others choose to use, but I will say this:
Having more of this process in Smalltalk and less in other (arcane) languages increases the confidence that, should we lose someone's services, others could step up to fill the gap.
Cheers, Bob
On 11/7/13 8:28 AM, Igor Stasenko wrote:
Ec7Xf8-DaANjijv1beYiqxBApPntNg@mail.gmail.com" type="cite">
On 7 November 2013 08:58, Tobias Pape <Das.Linux@gmx.de> wrote: Hey Tim and all, On 07.11.2013, at 05:00, Ron Teitelbaum <ron@usmedrec.com> wrote:
> Hey Tim, > > Göran and Eliot have been discussing this. I just talked to Eliot about it > yesterday. He said he was happy to support cmake but didn't want to have to > do the work himself. I'm hoping that the work Göran is doing on this now > can be turned over to Eliot when it is finished. I think there is agreement > that combining the excellent work of pharo build with Eliot's new vm work is > a very good thing to do. The work to merge the build environments is > already being done at 3D ICC. We are working on this for the Mac also but > have not discussed it with Ian yet. > > Ron Teitelbaum > >> -----Original Message----- >> From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- >> bounces@lists.squeakfoundation.org] On Behalf Of tim Rowledge >> Sent: Wednesday, November 06, 2013 9:04 PM >> To: The general-purpose Squeak developers list >> Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build > process >> >> >> Wow, no interest? Is it because make is painful or because nobody needs to >> make any more money?
I actually have interest but I am currently reluctant, for time-capturing reasons in my personal and work life.
However, Here is what I would do:
• Start from Ians CMake work, and try to generalize it for the non-Linux platforms • Windows would be kind-of straight-forward, • For OS X, I would really want to have the Cocoa-based VM stuff (aka Squeak VM 5.4.7.x) integrated and proper Xcode files generated, especially to be able to have iOS VMs built automatically. Here, some information from John McIntosh would be helpfull, especially a simple walk-through. I have some experience with that[1]
Despite all admiration I have for the way the PharoVM is built, there is one thing that bothers me: • You first somehow generate the VM sources (which is fine, and the automated way is amazing) • THEN, the a Script generates CMake-Files • CMake then generates Makefiles • and then finally a vm is compiled. This is one generating step too much, for my taste. Personally, I'd prefer CMake to just pick up the C-files generated by VMMaker, so that adding a new platform does not need to change the VMMaker…
The main big issue with 'platform-neutral' static source files, that they tend to
grow with tons of #ifdef-s over time, reducing readability and creating a mess.
My point is that one or another way you have to deal with platform differences,
and the way how i prefer to do it is using smalltalk code,
but not .m4 files, or .cmake files, or writing a medium novel long configuration files
using strange (better to say weird) scripting DSL.
I can express all build process logic in smalltalk, which does not lessens the amount of work to deal with all platform nuances and dependencies etc, but at least it allows me to organize and shape it into some manageable form, which is easy to change & learn.
And another difference is, that i prefer working with browser & classes than with dozens of directories and files lying here and there.
But sure thing, it is a question of taste. If you prefer to maintain this: ------------------------- MACRO (INTERNAL_PLUGIN plugin) SET (plugin_sources "") IF (DEFINED ${plugin}_sources) SET (plugin_sources ${${plugin}_sources}) ELSE (DEFINED ${plugin}_sources) FOREACH (dir ${src}/vm/intplugins ${cross}/plugins ${unix}/plugins) SET (tmp "") AUX_SOURCE_DIRECTORY (${dir}/${plugin} tmp) STRING_APPEND (plugin_sources "${tmp}") ENDFOREACH (dir) ENDIF (DEFINED ${plugin}_sources) IF (DEFINED ${plugin}_extra_sources) STRING_APPEND (plugin_sources "${${plugin}_extra_sources}") ENDIF (DEFINED ${plugin}_extra_sources) FILE (WRITE ${bld}/${plugin}/CMakeLists.in "") FOREACH (dir ${unix}/plugins ${unix}) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${dir}/${plugin}/build.cmake) ENDFOREACH (dir) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${config}/PluginInternal.cmake) CONFIGURE_FILE (${bld}/${plugin}/CMakeLists.in ${bld}/${plugin}/CMakeLists.txt @ONLY) ADD_SUBDIRECTORY (${bld}/${plugin} ${bld}/${plugin}) ENDMACRO (INTERNAL_PLUGIN) --------------------------
And/or this: -------------------------- AC_INIT([config.h.in])
SVNREV=`grep '$Rev: ' ${srcdir}/../../../platforms/Cross/vm/sqSCCSVersion.h \ | sed 's/.*$Rev: ([[0-9]][[0-9]]*).*/\1/'` AC_VM_VERSION(4,0,${SVNREV},4,2,0)
topdir=`cd ${srcdir}/../../..; pwd` cfgdir=`cd ${srcdir}; pwd`
AC_ARG_WITH(src, [ --with-src=dir generated src directory [default=src]], [ vmmsrc="${with_src}"], [ vmmsrc="src"])
vmmdir="${topdir}/${vmmsrc}"
if test ! -d "${topdir}/${vmmsrc}"; then if test -d "${topdir}/platforms/unix/${vmmsrc}"; then vmmdir="${topdir}/platforms/unix/${vmmsrc}" AC_MSG_RESULT([using built-in src directory]) fi fi
AC_MSG_RESULT(${vmmdir})
blddir=`pwd`
AC_ARG_WITH(vmmcfg, [ --with-vmmcfg=dir vm configuration directory containing plugins.int and plugins.ext [default=.]], [ vmmcfg="${with-vmmcfg}"], [ vmmcfg="${blddir}"])
# Compiling a Cogit VM or not? If so, need a cogit$o, cointerp, etc.
AC_ARG_ENABLE(cogit, [ --enable-cogit compile a cogit VM [default=yes]], cogit="no", cogit="yes") AC_SUBST(cogit)
#AC_ARG_ENABLE(jit, #[ --enable-jit enable J4 support [default=no]], #JIT="yes", JIT="no") # #test $JIT = "yes" && J_CFLAGS="-DJ_ENABLED" #AC_SUBST(J_CFLAGS)
# Check the generated src dir looks sane
AC_CHECK_VMM_DIR
AC_SUBST(topdir) AC_SUBST(cfgdir) AC_SUBST(vmmdir) AC_SUBST(vmmcfg) AC_SUBST(blddir)
SQ_VERSION=${SQ_MAJOR}.${SQ_MINOR}-${SQ_UPDATE}
AC_DEFINE_UNQUOTED(SQ_VERSION, "${SQ_VERSION}")
AC_SUBST(SQ_MAJOR) AC_SUBST(SQ_MINOR) AC_SUBST(SQ_UPDATE) AC_SUBST(SQ_VERSION)
VM_VERSION=${VM_MAJOR}.${VM_MINOR}-${VM_RELEASE}
AC_DEFINE_UNQUOTED(VM_VERSION, "${VM_VERSION}")
AC_SUBST(VM_MAJOR) AC_SUBST(VM_MINOR) AC_SUBST(VM_RELEASE) AC_SUBST(VM_VERSION)
# libdir contains ${exec_prefix}, so we have to default and expand early test "x$prefix" = xNONE && prefix=$ac_default_prefix test "x$exec_prefix" = xNONE && exec_prefix='${prefix}' imgdir=`eval echo ${libdir}/squeak` expanded_relative_imgdir=`eval echo lib/squeak/${VM_VERSION}` plgdir='${imgdir}/'`eval echo ${VM_VERSION}`
AC_SUBST(imgdir) AC_SUBST(expanded_relative_imgdir) AC_SUBST(plgdir)
AC_DEFINE(OS_TYPE, "unix")
AC_CANONICAL_HOST
host_cpu=`echo $host | sed 's,-.*,,'` host=`echo $host | sed 's,-unknown,,'`
AC_SUBST(host) AC_SUBST(host_cpu) AC_SUBST(host_vendor) AC_SUBST(host_os) ----------------------------
instead of plain smalltalk code, it is up to you.
But that's about 'too much' for my taste.
But if the community is positive to just move to the Pharo way of building VMs, I'd be fine with that, since that would unify a lot of infrastructure :)
Best -Tobias
[1] https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake
-- Best regards, Igor Stasenko.
Hi Timothy,
On Thu, Nov 7, 2013 at 12:33 PM, gettimothy gettimothy@zoho.com wrote:
Eliot,
Thank you so much for the reply.
Currently my low-level skills are atrophied and have organized my work-life to devote study time to regaining and improving them. This is a great opportunity to contribute and get my chops up in the process.
When you refer to 'machine code' and 'machine organization' do you mean the Cog/Squeak VM's or the AMD 64 instruction set? (I lack both, but if you mean the VM, a good exercise in learning it would be writing some good documentation on it)
I mean good low-level programming skills. Knowing how stacks and address spaces are organized, what the machine's calling convention is, what a system call looks like, etc, and what the current processor's instruction set is, it's theory etc (is it a RISC or a CISC; does it have delay slots, etc, etc).
So first things first. Get the stack VM wokring in 64-bits.
From your reply, I guess I would best be of use getting the Stack VM working in 64 bits--its something I am currently attempting to do.
I have a tri-boot machine--Windows 7, Linux with 32 bit compat libs--where I can run smalltalk, and a pure 64 bit boot, where I cannot run smalltalk.
OK, but right now you'll want to be in Smalltalk, and for quite a while.
I am currently attempting to get the source code from http://www.squeakvm.org/squeak64/ Squeak-3.8a-2.src.tar.gz to compile on the pure 64 box. The Quick Start steps failed, so I am now setting about studying the source code in merge64/platforms/unix/vm/sqUnixMain.c as it looks like the entry point for the VM. In the back of my mind, I am wondering if this is even the right approach to take..
It's not :-).
What do you think is the best approach to take?
Read the latest two articles on my blog (A Spur gear for Coghttp://www.mirandabanda.org/cogblog/2013/09/05/a-spur-gear-for-cog/ & Lazy Becomehttp://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-and-a-partial-read-barrier/ ). Make a VMMaker image (see e.g. Cog Blog :: Building a Cog Development Imagehttp://www.google.com/url?sa=t&rct=j&q=create%20a%20cog%20vmmaker%20image&source=web&cd=1&cad=rja&ved=0CCsQFjAA&url=http%3A%2F%2Fwww.mirandabanda.org%2Fcogblog%2Fbuild-image%2F&ei=sQp8UsnDL8GLjALn6oDICQ&usg=AFQjCNHoDMjPg2Sy7huxuOSDrTIyHo_RNw&sig2=s3vx6j1rl73gdHq37BMiiQ&bvm=bv.56146854,d.cGE ). Then read SpurMemoryManager, /especially/ its class comment. Then read its subclasses Spur32BitMemoryManager (functional) & Spur64BitMemoryManager (completely untested). Then read SpurBootstrap32. Try and create a 32-bit Spur image and run it. Then try and implement SpurBootstrap64. Try and create a 64-bit Spur image and run it.
This is /lots/ of work. In particular the last two steps require some significant design. So start slowly and see how you get on.
Cordially,
t
---- On Thu, 07 Nov 2013 10:54:01 -0800 *Eliot Miranda<eliot.miranda@gmail.com eliot.miranda@gmail.com>* wrote ----
Hi Timothy,
On Thu, Nov 7, 2013 at 7:02 AM, gettimothy gettimothy@zoho.com wrote:
Is there any chance Cog could be made to run on AMD64 natively without 32 bit libs?
Yes, that's a goal of my current work. Spur has a common object representation between 32- and 64-bits. Getting to a native Stack VM on AMD64 should be straight-forward. Getting to a Cog VM on AMD64 also requires writing a code generator for AMD64. That's actually a fun project. It involves configuring a Bochs plugin for an AMD64/IA32 simulator, and then writing a CogIA64Compiler subclass of CogAbstractInstruction.
If so, I would like to help out with whoever takes up this task. I would need direction, however as I have been do app development for too many years and my sys skills are atrophied.
How strong are your low-level skills? You'll need to be quite familiar with machine code, basic machine organization, etc. If you're not then you could instead have a go at getting the Stack VM working in 64-bits, and that would involve getting the 64-bit VM simulator working in VMMaker.
It will be great to have another collaborator!
t.
---- On Thu, 07 Nov 2013 06:01:00 -0800 *Bob Arning<arning315@comcast.net arning315@comcast.net>* wrote ----
It's absolutely none of my business what tools others choose to use, but I will say this:
Having more of this process in Smalltalk and less in other (arcane) languages increases the confidence that, should we lose someone's services, others could step up to fill the gap.
Cheers, Bob
On 11/7/13 8:28 AM, Igor Stasenko wrote:
Ec7Xf8-DaANjijv1beYiqxBApPntNg@mail.gmail.com" type="cite">
On 7 November 2013 08:58, Tobias Pape Das.Linux@gmx.de wrote:
Hey Tim and all, On 07.11.2013, at 05:00, Ron Teitelbaum ron@usmedrec.com wrote:
Hey Tim,
Göran and Eliot have been discussing this. I just talked to Eliot about
it
yesterday. He said he was happy to support cmake but didn't want to
have to
do the work himself. I'm hoping that the work Göran is doing on this now can be turned over to Eliot when it is finished. I think there is
agreement
that combining the excellent work of pharo build with Eliot's new vm
work is
a very good thing to do. The work to merge the build environments is already being done at 3D ICC. We are working on this for the Mac also
but
have not discussed it with Ian yet.
Ron Teitelbaum
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of tim Rowledge Sent: Wednesday, November 06, 2013 9:04 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build
process
Wow, no interest? Is it because make is painful or because nobody needs
to
make any more money?
I actually have interest but I am currently reluctant, for time-capturing reasons in my personal and work life.
However, Here is what I would do:
• Start from Ians CMake work, and try to generalize it for the non-Linux platforms • Windows would be kind-of straight-forward, • For OS X, I would really want to have the Cocoa-based VM stuff (aka Squeak VM 5.4.7.x) integrated and proper Xcode files generated, especially to be able to have iOS VMs built automatically. Here, some information from John McIntosh would be helpfull, especially a simple walk-through. I have some experience with that[1]
Despite all admiration I have for the way the PharoVM is built, there is one thing that bothers me: • You first somehow generate the VM sources (which is fine, and the automated way is amazing) • THEN, the a Script generates CMake-Files • CMake then generates Makefiles • and then finally a vm is compiled. This is one generating step too much, for my taste. Personally, I'd prefer CMake to just pick up the C-files generated by VMMaker, so that adding a new platform does not need to change the VMMaker…
The main big issue with 'platform-neutral' static source files, that they tend to grow with tons of #ifdef-s over time, reducing readability and creating a mess.
My point is that one or another way you have to deal with platform differences, and the way how i prefer to do it is using smalltalk code, but not .m4 files, or .cmake files, or writing a medium novel long configuration files using strange (better to say weird) scripting DSL. I can express all build process logic in smalltalk, which does not lessens the amount of work to deal with all platform nuances and dependencies etc, but at least it allows me to organize and shape it into some manageable form, which is easy to change & learn.
And another difference is, that i prefer working with browser & classes than with dozens of directories and files lying here and there.
But sure thing, it is a question of taste. If you prefer to maintain this:
MACRO (INTERNAL_PLUGIN plugin) SET (plugin_sources "") IF (DEFINED ${plugin}_sources) SET (plugin_sources ${${plugin}_sources}) ELSE (DEFINED ${plugin}_sources) FOREACH (dir ${src}/vm/intplugins ${cross}/plugins ${unix}/plugins) SET (tmp "") AUX_SOURCE_DIRECTORY (${dir}/${plugin} tmp) STRING_APPEND (plugin_sources "${tmp}") ENDFOREACH (dir) ENDIF (DEFINED ${plugin}_sources) IF (DEFINED ${plugin}_extra_sources) STRING_APPEND (plugin_sources "${${plugin}_extra_sources}") ENDIF (DEFINED ${plugin}_extra_sources) FILE (WRITE ${bld}/${plugin}/CMakeLists.in "") FOREACH (dir ${unix}/plugins ${unix}) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${dir}/${plugin}/build.cmake) ENDFOREACH (dir) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${config}/PluginInternal.cmake) CONFIGURE_FILE (${bld}/${plugin}/CMakeLists.in ${bld}/${plugin}/CMakeLists.txt @ONLY) ADD_SUBDIRECTORY (${bld}/${plugin} ${bld}/${plugin}) ENDMACRO (INTERNAL_PLUGIN)
And/or this:
AC_INIT([config.h.in])
SVNREV=`grep '$Rev: ' ${srcdir}/../../../platforms/Cross/vm/sqSCCSVersion.h \ | sed 's/.*$Rev: ([[0-9]][[0-9]]*).*/\1/'` AC_VM_VERSION(4,0,${SVNREV},4,2,0)
topdir=`cd ${srcdir}/../../..; pwd` cfgdir=`cd ${srcdir}; pwd`
AC_ARG_WITH(src, [ --with-src=dir generated src directory [default=src]], [ vmmsrc="${with_src}"], [ vmmsrc="src"])
vmmdir="${topdir}/${vmmsrc}"
if test ! -d "${topdir}/${vmmsrc}"; then if test -d "${topdir}/platforms/unix/${vmmsrc}"; then vmmdir="${topdir}/platforms/unix/${vmmsrc}" AC_MSG_RESULT([using built-in src directory]) fi fi
AC_MSG_RESULT(${vmmdir})
blddir=`pwd`
AC_ARG_WITH(vmmcfg, [ --with-vmmcfg=dir vm configuration directory containing plugins.int and plugins.ext [default=.]], [ vmmcfg="${with-vmmcfg}"], [ vmmcfg="${blddir}"])
# Compiling a Cogit VM or not? If so, need a cogit$o, cointerp, etc.
AC_ARG_ENABLE(cogit, [ --enable-cogit compile a cogit VM [default=yes]], cogit="no", cogit="yes") AC_SUBST(cogit)
#AC_ARG_ENABLE(jit, #[ --enable-jit enable J4 support [default=no]], #JIT="yes", JIT="no") # #test $JIT = "yes" && J_CFLAGS="-DJ_ENABLED" #AC_SUBST(J_CFLAGS)
# Check the generated src dir looks sane
AC_CHECK_VMM_DIR
AC_SUBST(topdir) AC_SUBST(cfgdir) AC_SUBST(vmmdir) AC_SUBST(vmmcfg) AC_SUBST(blddir)
SQ_VERSION=${SQ_MAJOR}.${SQ_MINOR}-${SQ_UPDATE}
AC_DEFINE_UNQUOTED(SQ_VERSION, "${SQ_VERSION}")
AC_SUBST(SQ_MAJOR) AC_SUBST(SQ_MINOR) AC_SUBST(SQ_UPDATE) AC_SUBST(SQ_VERSION)
VM_VERSION=${VM_MAJOR}.${VM_MINOR}-${VM_RELEASE}
AC_DEFINE_UNQUOTED(VM_VERSION, "${VM_VERSION}")
AC_SUBST(VM_MAJOR) AC_SUBST(VM_MINOR) AC_SUBST(VM_RELEASE) AC_SUBST(VM_VERSION)
# libdir contains ${exec_prefix}, so we have to default and expand early test "x$prefix" = xNONE && prefix=$ac_default_prefix test "x$exec_prefix" = xNONE && exec_prefix='${prefix}' imgdir=`eval echo ${libdir}/squeak` expanded_relative_imgdir=`eval echo lib/squeak/${VM_VERSION}` plgdir='${imgdir}/'`eval echo ${VM_VERSION}`
AC_SUBST(imgdir) AC_SUBST(expanded_relative_imgdir) AC_SUBST(plgdir)
AC_DEFINE(OS_TYPE, "unix")
AC_CANONICAL_HOST
host_cpu=`echo $host | sed 's,-.*,,'` host=`echo $host | sed 's,-unknown,,'`
AC_SUBST(host) AC_SUBST(host_cpu) AC_SUBST(host_vendor) AC_SUBST(host_os)
instead of plain smalltalk code, it is up to you.
But that's about 'too much' for my taste.
But if the community is positive to just move to the Pharo way of building VMs, I'd be fine with that, since that would unify a lot of infrastructure :)
Best -Tobias
[1] https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake
-- Best regards, Igor Stasenko.
-- best, Eliot
Awesome,
Thank you.
t
---- On Thu, 07 Nov 2013 13:54:03 -0800 Eliot Miranda <eliot.miranda@gmail.com> wrote ----
Hi Timothy, On Thu, Nov 7, 2013 at 12:33 PM, gettimothy <gettimothy@zoho.com> wrote: Eliot,
Thank you so much for the reply.
Currently my low-level skills are atrophied and have organized my work-life to devote study time to regaining and improving them. This is a great opportunity to contribute and get my chops up in the process.
When you refer to 'machine code' and 'machine organization' do you mean the Cog/Squeak VM's or the AMD 64 instruction set? (I lack both, but if you mean the VM, a good exercise in learning it would be writing some good documentation on it)
I mean good low-level programming skills. Knowing how stacks and address spaces are organized, what the machine's calling convention is, what a system call looks like, etc, and what the current processor's instruction set is, it's theory etc (is it a RISC or a CISC; does it have delay slots, etc, etc).
So first things first. Get the stack VM wokring in 64-bits.
From your reply, I guess I would best be of use getting the Stack VM working in 64 bits--its something I am currently attempting to do.
I have a tri-boot machine--Windows 7, Linux with 32 bit compat libs--where I can run smalltalk, and a pure 64 bit boot, where I cannot run smalltalk.
OK, but right now you'll want to be in Smalltalk, and for quite a while.
I am currently attempting to get the source code from http://www.squeakvm.org/squeak64/ Squeak-3.8a-2.src.tar.gz to compile on the pure 64 box. The Quick Start steps failed, so I am now setting about studying the source code in merge64/platforms/unix/vm/sqUnixMain.c as it looks like the entry point for the VM. In the back of my mind, I am wondering if this is even the right approach to take..
It's not :-).
What do you think is the best approach to take?
Read the latest two articles on my blog (A Spur gear for Cog & Lazy Become). Make a VMMaker image (see e.g. Cog Blog :: Building a Cog Development Image). Then read SpurMemoryManager, /especially/ its class comment. Then read its subclasses Spur32BitMemoryManager (functional) & Spur64BitMemoryManager (completely untested). Then read SpurBootstrap32. Try and create a 32-bit Spur image and run it. Then try and implement SpurBootstrap64. Try and create a 64-bit Spur image and run it.
This is /lots/ of work. In particular the last two steps require some significant design. So start slowly and see how you get on.
Cordially,
t
---- On Thu, 07 Nov 2013 10:54:01 -0800 Eliot Miranda<eliot.miranda@gmail.com> wrote ----
Hi Timothy,
On Thu, Nov 7, 2013 at 7:02 AM, gettimothy <gettimothy@zoho.com> wrote: Is there any chance Cog could be made to run on AMD64 natively without 32 bit libs?
Yes, that's a goal of my current work. Spur has a common object representation between 32- and 64-bits. Getting to a native Stack VM on AMD64 should be straight-forward. Getting to a Cog VM on AMD64 also requires writing a code generator for AMD64. That's actually a fun project. It involves configuring a Bochs plugin for an AMD64/IA32 simulator, and then writing a CogIA64Compiler subclass of CogAbstractInstruction.
If so, I would like to help out with whoever takes up this task. I would need direction, however as I have been do app development for too many years and my sys skills are atrophied.
How strong are your low-level skills? You'll need to be quite familiar with machine code, basic machine organization, etc. If you're not then you could instead have a go at getting the Stack VM working in 64-bits, and that would involve getting the 64-bit VM simulator working in VMMaker.
It will be great to have another collaborator!
t.
---- On Thu, 07 Nov 2013 06:01:00 -0800 Bob Arning<arning315@comcast.net> wrote ----
It's absolutely none of my business what tools others choose to use, but I will say this:
Having more of this process in Smalltalk and less in other (arcane) languages increases the confidence that, should we lose someone's services, others could step up to fill the gap.
Cheers, Bob
On 11/7/13 8:28 AM, Igor Stasenko wrote:
Ec7Xf8-DaANjijv1beYiqxBApPntNg@mail.gmail.com" type="cite">
On 7 November 2013 08:58, Tobias Pape <Das.Linux@gmx.de> wrote: Hey Tim and all, On 07.11.2013, at 05:00, Ron Teitelbaum <ron@usmedrec.com> wrote:
> Hey Tim, > > Göran and Eliot have been discussing this. I just talked to Eliot about it > yesterday. He said he was happy to support cmake but didn't want to have to > do the work himself. I'm hoping that the work Göran is doing on this now > can be turned over to Eliot when it is finished. I think there is agreement > that combining the excellent work of pharo build with Eliot's new vm work is > a very good thing to do. The work to merge the build environments is > already being done at 3D ICC. We are working on this for the Mac also but > have not discussed it with Ian yet. > > Ron Teitelbaum > >> -----Original Message----- >> From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- >> bounces@lists.squeakfoundation.org] On Behalf Of tim Rowledge >> Sent: Wednesday, November 06, 2013 9:04 PM >> To: The general-purpose Squeak developers list >> Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build > process >> >> >> Wow, no interest? Is it because make is painful or because nobody needs to >> make any more money?
I actually have interest but I am currently reluctant, for time-capturing reasons in my personal and work life.
However, Here is what I would do:
• Start from Ians CMake work, and try to generalize it for the non-Linux platforms • Windows would be kind-of straight-forward, • For OS X, I would really want to have the Cocoa-based VM stuff (aka Squeak VM 5.4.7.x) integrated and proper Xcode files generated, especially to be able to have iOS VMs built automatically. Here, some information from John McIntosh would be helpfull, especially a simple walk-through. I have some experience with that[1]
Despite all admiration I have for the way the PharoVM is built, there is one thing that bothers me: • You first somehow generate the VM sources (which is fine, and the automated way is amazing) • THEN, the a Script generates CMake-Files • CMake then generates Makefiles • and then finally a vm is compiled. This is one generating step too much, for my taste. Personally, I'd prefer CMake to just pick up the C-files generated by VMMaker, so that adding a new platform does not need to change the VMMaker…
The main big issue with 'platform-neutral' static source files, that they tend to
grow with tons of #ifdef-s over time, reducing readability and creating a mess.
My point is that one or another way you have to deal with platform differences,
and the way how i prefer to do it is using smalltalk code,
but not .m4 files, or .cmake files, or writing a medium novel long configuration files
using strange (better to say weird) scripting DSL.
I can express all build process logic in smalltalk, which does not lessens the amount of work to deal with all platform nuances and dependencies etc, but at least it allows me to organize and shape it into some manageable form, which is easy to change & learn.
And another difference is, that i prefer working with browser & classes than with dozens of directories and files lying here and there.
But sure thing, it is a question of taste. If you prefer to maintain this: ------------------------- MACRO (INTERNAL_PLUGIN plugin) SET (plugin_sources "") IF (DEFINED ${plugin}_sources) SET (plugin_sources ${${plugin}_sources}) ELSE (DEFINED ${plugin}_sources) FOREACH (dir ${src}/vm/intplugins ${cross}/plugins ${unix}/plugins) SET (tmp "") AUX_SOURCE_DIRECTORY (${dir}/${plugin} tmp) STRING_APPEND (plugin_sources "${tmp}") ENDFOREACH (dir) ENDIF (DEFINED ${plugin}_sources) IF (DEFINED ${plugin}_extra_sources) STRING_APPEND (plugin_sources "${${plugin}_extra_sources}") ENDIF (DEFINED ${plugin}_extra_sources) FILE (WRITE ${bld}/${plugin}/CMakeLists.in "") FOREACH (dir ${unix}/plugins ${unix}) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${dir}/${plugin}/build.cmake) ENDFOREACH (dir) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${config}/PluginInternal.cmake) CONFIGURE_FILE (${bld}/${plugin}/CMakeLists.in ${bld}/${plugin}/CMakeLists.txt @ONLY) ADD_SUBDIRECTORY (${bld}/${plugin} ${bld}/${plugin}) ENDMACRO (INTERNAL_PLUGIN) --------------------------
And/or this: -------------------------- AC_INIT([config.h.in])
SVNREV=`grep '$Rev: ' ${srcdir}/../../../platforms/Cross/vm/sqSCCSVersion.h \ | sed 's/.*$Rev: ([[0-9]][[0-9]]*).*/\1/'` AC_VM_VERSION(4,0,${SVNREV},4,2,0)
topdir=`cd ${srcdir}/../../..; pwd` cfgdir=`cd ${srcdir}; pwd`
AC_ARG_WITH(src, [ --with-src=dir generated src directory [default=src]], [ vmmsrc="${with_src}"], [ vmmsrc="src"])
vmmdir="${topdir}/${vmmsrc}"
if test ! -d "${topdir}/${vmmsrc}"; then if test -d "${topdir}/platforms/unix/${vmmsrc}"; then vmmdir="${topdir}/platforms/unix/${vmmsrc}" AC_MSG_RESULT([using built-in src directory]) fi fi
AC_MSG_RESULT(${vmmdir})
blddir=`pwd`
AC_ARG_WITH(vmmcfg, [ --with-vmmcfg=dir vm configuration directory containing plugins.int and plugins.ext [default=.]], [ vmmcfg="${with-vmmcfg}"], [ vmmcfg="${blddir}"])
# Compiling a Cogit VM or not? If so, need a cogit$o, cointerp, etc.
AC_ARG_ENABLE(cogit, [ --enable-cogit compile a cogit VM [default=yes]], cogit="no", cogit="yes") AC_SUBST(cogit)
#AC_ARG_ENABLE(jit, #[ --enable-jit enable J4 support [default=no]], #JIT="yes", JIT="no") # #test $JIT = "yes" && J_CFLAGS="-DJ_ENABLED" #AC_SUBST(J_CFLAGS)
# Check the generated src dir looks sane
AC_CHECK_VMM_DIR
AC_SUBST(topdir) AC_SUBST(cfgdir) AC_SUBST(vmmdir) AC_SUBST(vmmcfg) AC_SUBST(blddir)
SQ_VERSION=${SQ_MAJOR}.${SQ_MINOR}-${SQ_UPDATE}
AC_DEFINE_UNQUOTED(SQ_VERSION, "${SQ_VERSION}")
AC_SUBST(SQ_MAJOR) AC_SUBST(SQ_MINOR) AC_SUBST(SQ_UPDATE) AC_SUBST(SQ_VERSION)
VM_VERSION=${VM_MAJOR}.${VM_MINOR}-${VM_RELEASE}
AC_DEFINE_UNQUOTED(VM_VERSION, "${VM_VERSION}")
AC_SUBST(VM_MAJOR) AC_SUBST(VM_MINOR) AC_SUBST(VM_RELEASE) AC_SUBST(VM_VERSION)
# libdir contains ${exec_prefix}, so we have to default and expand early test "x$prefix" = xNONE && prefix=$ac_default_prefix test "x$exec_prefix" = xNONE && exec_prefix='${prefix}' imgdir=`eval echo ${libdir}/squeak` expanded_relative_imgdir=`eval echo lib/squeak/${VM_VERSION}` plgdir='${imgdir}/'`eval echo ${VM_VERSION}`
AC_SUBST(imgdir) AC_SUBST(expanded_relative_imgdir) AC_SUBST(plgdir)
AC_DEFINE(OS_TYPE, "unix")
AC_CANONICAL_HOST
host_cpu=`echo $host | sed 's,-.*,,'` host=`echo $host | sed 's,-unknown,,'`
AC_SUBST(host) AC_SUBST(host_cpu) AC_SUBST(host_vendor) AC_SUBST(host_os) ----------------------------
instead of plain smalltalk code, it is up to you.
But that's about 'too much' for my taste.
But if the community is positive to just move to the Pharo way of building VMs, I'd be fine with that, since that would unify a lot of infrastructure :)
Best -Tobias
[1] https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake
-- Best regards, Igor Stasenko.
Eliot,
Re "I mean good low-level programming skills. Knowing how stacks and address spaces are organized, what the machine's calling convention is, what a system call looks like, etc, and what the current processor's instruction set is, it's theory etc (is it a RISC or a CISC; does it have delay slots, etc, etc)."
Would an updated edition of Patterson and Hennessy be helpful here? My copy (like my c skills) is from 1993.
t.
---- On Thu, 07 Nov 2013 13:54:03 -0800 Eliot Miranda<eliot.miranda@gmail.com> wrote ----
Hi Timothy, On Thu, Nov 7, 2013 at 12:33 PM, gettimothy <gettimothy@zoho.com> wrote: Eliot,
Thank you so much for the reply.
Currently my low-level skills are atrophied and have organized my work-life to devote study time to regaining and improving them. This is a great opportunity to contribute and get my chops up in the process.
When you refer to 'machine code' and 'machine organization' do you mean the Cog/Squeak VM's or the AMD 64 instruction set? (I lack both, but if you mean the VM, a good exercise in learning it would be writing some good documentation on it)
I mean good low-level programming skills. Knowing how stacks and address spaces are organized, what the machine's calling convention is, what a system call looks like, etc, and what the current processor's instruction set is, it's theory etc (is it a RISC or a CISC; does it have delay slots, etc, etc).
So first things first. Get the stack VM wokring in 64-bits.
From your reply, I guess I would best be of use getting the Stack VM working in 64 bits--its something I am currently attempting to do.
I have a tri-boot machine--Windows 7, Linux with 32 bit compat libs--where I can run smalltalk, and a pure 64 bit boot, where I cannot run smalltalk.
OK, but right now you'll want to be in Smalltalk, and for quite a while.
I am currently attempting to get the source code from http://www.squeakvm.org/squeak64/ Squeak-3.8a-2.src.tar.gz to compile on the pure 64 box. The Quick Start steps failed, so I am now setting about studying the source code in merge64/platforms/unix/vm/sqUnixMain.c as it looks like the entry point for the VM. In the back of my mind, I am wondering if this is even the right approach to take..
It's not :-).
What do you think is the best approach to take?
Read the latest two articles on my blog (A Spur gear for Cog & Lazy Become). Make a VMMaker image (see e.g. Cog Blog :: Building a Cog Development Image). Then read SpurMemoryManager, /especially/ its class comment. Then read its subclasses Spur32BitMemoryManager (functional) & Spur64BitMemoryManager (completely untested). Then read SpurBootstrap32. Try and create a 32-bit Spur image and run it. Then try and implement SpurBootstrap64. Try and create a 64-bit Spur image and run it.
This is /lots/ of work. In particular the last two steps require some significant design. So start slowly and see how you get on.
Cordially,
t
---- On Thu, 07 Nov 2013 10:54:01 -0800 Eliot Miranda<eliot.miranda@gmail.com> wrote ----
Hi Timothy,
On Thu, Nov 7, 2013 at 7:02 AM, gettimothy <gettimothy@zoho.com> wrote: Is there any chance Cog could be made to run on AMD64 natively without 32 bit libs?
Yes, that's a goal of my current work. Spur has a common object representation between 32- and 64-bits. Getting to a native Stack VM on AMD64 should be straight-forward. Getting to a Cog VM on AMD64 also requires writing a code generator for AMD64. That's actually a fun project. It involves configuring a Bochs plugin for an AMD64/IA32 simulator, and then writing a CogIA64Compiler subclass of CogAbstractInstruction.
If so, I would like to help out with whoever takes up this task. I would need direction, however as I have been do app development for too many years and my sys skills are atrophied.
How strong are your low-level skills? You'll need to be quite familiar with machine code, basic machine organization, etc. If you're not then you could instead have a go at getting the Stack VM working in 64-bits, and that would involve getting the 64-bit VM simulator working in VMMaker.
It will be great to have another collaborator!
t.
---- On Thu, 07 Nov 2013 06:01:00 -0800 Bob Arning<arning315@comcast.net> wrote ----
It's absolutely none of my business what tools others choose to use, but I will say this:
Having more of this process in Smalltalk and less in other (arcane) languages increases the confidence that, should we lose someone's services, others could step up to fill the gap.
Cheers, Bob
On 11/7/13 8:28 AM, Igor Stasenko wrote:
Ec7Xf8-DaANjijv1beYiqxBApPntNg@mail.gmail.com" type="cite">
On 7 November 2013 08:58, Tobias Pape <Das.Linux@gmx.de> wrote: Hey Tim and all, On 07.11.2013, at 05:00, Ron Teitelbaum <ron@usmedrec.com> wrote:
> Hey Tim, > > Göran and Eliot have been discussing this. I just talked to Eliot about it > yesterday. He said he was happy to support cmake but didn't want to have to > do the work himself. I'm hoping that the work Göran is doing on this now > can be turned over to Eliot when it is finished. I think there is agreement > that combining the excellent work of pharo build with Eliot's new vm work is > a very good thing to do. The work to merge the build environments is > already being done at 3D ICC. We are working on this for the Mac also but > have not discussed it with Ian yet. > > Ron Teitelbaum > >> -----Original Message----- >> From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- >> bounces@lists.squeakfoundation.org] On Behalf Of tim Rowledge >> Sent: Wednesday, November 06, 2013 9:04 PM >> To: The general-purpose Squeak developers list >> Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build > process >> >> >> Wow, no interest? Is it because make is painful or because nobody needs to >> make any more money?
I actually have interest but I am currently reluctant, for time-capturing reasons in my personal and work life.
However, Here is what I would do:
• Start from Ians CMake work, and try to generalize it for the non-Linux platforms • Windows would be kind-of straight-forward, • For OS X, I would really want to have the Cocoa-based VM stuff (aka Squeak VM 5.4.7.x) integrated and proper Xcode files generated, especially to be able to have iOS VMs built automatically. Here, some information from John McIntosh would be helpfull, especially a simple walk-through. I have some experience with that[1]
Despite all admiration I have for the way the PharoVM is built, there is one thing that bothers me: • You first somehow generate the VM sources (which is fine, and the automated way is amazing) • THEN, the a Script generates CMake-Files • CMake then generates Makefiles • and then finally a vm is compiled. This is one generating step too much, for my taste. Personally, I'd prefer CMake to just pick up the C-files generated by VMMaker, so that adding a new platform does not need to change the VMMaker…
The main big issue with 'platform-neutral' static source files, that they tend to
grow with tons of #ifdef-s over time, reducing readability and creating a mess.
My point is that one or another way you have to deal with platform differences,
and the way how i prefer to do it is using smalltalk code,
but not .m4 files, or .cmake files, or writing a medium novel long configuration files
using strange (better to say weird) scripting DSL.
I can express all build process logic in smalltalk, which does not lessens the amount of work to deal with all platform nuances and dependencies etc, but at least it allows me to organize and shape it into some manageable form, which is easy to change & learn.
And another difference is, that i prefer working with browser & classes than with dozens of directories and files lying here and there.
But sure thing, it is a question of taste. If you prefer to maintain this: ------------------------- MACRO (INTERNAL_PLUGIN plugin) SET (plugin_sources "") IF (DEFINED ${plugin}_sources) SET (plugin_sources ${${plugin}_sources}) ELSE (DEFINED ${plugin}_sources) FOREACH (dir ${src}/vm/intplugins ${cross}/plugins ${unix}/plugins) SET (tmp "") AUX_SOURCE_DIRECTORY (${dir}/${plugin} tmp) STRING_APPEND (plugin_sources "${tmp}") ENDFOREACH (dir) ENDIF (DEFINED ${plugin}_sources) IF (DEFINED ${plugin}_extra_sources) STRING_APPEND (plugin_sources "${${plugin}_extra_sources}") ENDIF (DEFINED ${plugin}_extra_sources) FILE (WRITE ${bld}/${plugin}/CMakeLists.in "") FOREACH (dir ${unix}/plugins ${unix}) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${dir}/${plugin}/build.cmake) ENDFOREACH (dir) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${config}/PluginInternal.cmake) CONFIGURE_FILE (${bld}/${plugin}/CMakeLists.in ${bld}/${plugin}/CMakeLists.txt @ONLY) ADD_SUBDIRECTORY (${bld}/${plugin} ${bld}/${plugin}) ENDMACRO (INTERNAL_PLUGIN) --------------------------
And/or this: -------------------------- AC_INIT([config.h.in])
SVNREV=`grep '$Rev: ' ${srcdir}/../../../platforms/Cross/vm/sqSCCSVersion.h \ | sed 's/.*$Rev: ([[0-9]][[0-9]]*).*/\1/'` AC_VM_VERSION(4,0,${SVNREV},4,2,0)
topdir=`cd ${srcdir}/../../..; pwd` cfgdir=`cd ${srcdir}; pwd`
AC_ARG_WITH(src, [ --with-src=dir generated src directory [default=src]], [ vmmsrc="${with_src}"], [ vmmsrc="src"])
vmmdir="${topdir}/${vmmsrc}"
if test ! -d "${topdir}/${vmmsrc}"; then if test -d "${topdir}/platforms/unix/${vmmsrc}"; then vmmdir="${topdir}/platforms/unix/${vmmsrc}" AC_MSG_RESULT([using built-in src directory]) fi fi
AC_MSG_RESULT(${vmmdir})
blddir=`pwd`
AC_ARG_WITH(vmmcfg, [ --with-vmmcfg=dir vm configuration directory containing plugins.int and plugins.ext [default=.]], [ vmmcfg="${with-vmmcfg}"], [ vmmcfg="${blddir}"])
# Compiling a Cogit VM or not? If so, need a cogit$o, cointerp, etc.
AC_ARG_ENABLE(cogit, [ --enable-cogit compile a cogit VM [default=yes]], cogit="no", cogit="yes") AC_SUBST(cogit)
#AC_ARG_ENABLE(jit, #[ --enable-jit enable J4 support [default=no]], #JIT="yes", JIT="no") # #test $JIT = "yes" && J_CFLAGS="-DJ_ENABLED" #AC_SUBST(J_CFLAGS)
# Check the generated src dir looks sane
AC_CHECK_VMM_DIR
AC_SUBST(topdir) AC_SUBST(cfgdir) AC_SUBST(vmmdir) AC_SUBST(vmmcfg) AC_SUBST(blddir)
SQ_VERSION=${SQ_MAJOR}.${SQ_MINOR}-${SQ_UPDATE}
AC_DEFINE_UNQUOTED(SQ_VERSION, "${SQ_VERSION}")
AC_SUBST(SQ_MAJOR) AC_SUBST(SQ_MINOR) AC_SUBST(SQ_UPDATE) AC_SUBST(SQ_VERSION)
VM_VERSION=${VM_MAJOR}.${VM_MINOR}-${VM_RELEASE}
AC_DEFINE_UNQUOTED(VM_VERSION, "${VM_VERSION}")
AC_SUBST(VM_MAJOR) AC_SUBST(VM_MINOR) AC_SUBST(VM_RELEASE) AC_SUBST(VM_VERSION)
# libdir contains ${exec_prefix}, so we have to default and expand early test "x$prefix" = xNONE && prefix=$ac_default_prefix test "x$exec_prefix" = xNONE && exec_prefix='${prefix}' imgdir=`eval echo ${libdir}/squeak` expanded_relative_imgdir=`eval echo lib/squeak/${VM_VERSION}` plgdir='${imgdir}/'`eval echo ${VM_VERSION}`
AC_SUBST(imgdir) AC_SUBST(expanded_relative_imgdir) AC_SUBST(plgdir)
AC_DEFINE(OS_TYPE, "unix")
AC_CANONICAL_HOST
host_cpu=`echo $host | sed 's,-.*,,'` host=`echo $host | sed 's,-unknown,,'`
AC_SUBST(host) AC_SUBST(host_cpu) AC_SUBST(host_vendor) AC_SUBST(host_os) ----------------------------
instead of plain smalltalk code, it is up to you.
But that's about 'too much' for my taste.
But if the community is positive to just move to the Pharo way of building VMs, I'd be fine with that, since that would unify a lot of infrastructure :)
Best -Tobias
[1] https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake
-- Best regards, Igor Stasenko.
On Thu, Nov 7, 2013 at 3:16 PM, gettimothy gettimothy@zoho.com wrote:
Eliot,
Re "I mean good low-level programming skills. Knowing how stacks and address spaces are organized, what the machine's calling convention is, what a system call looks like, etc, and what the current processor's instruction set is, it's theory etc (is it a RISC or a CISC; does it have delay slots, etc, etc)."
Would an updated edition of Patterson and Hennessy be helpful here? My copy (like my c skills) is from 1993.
nothing fundamental that affects Cog has changed in that time... it'll do just fine.
t.
---- On Thu, 07 Nov 2013 13:54:03 -0800 *Eliot Miranda<eliot.miranda@gmail.com eliot.miranda@gmail.com>* wrote ----
Hi Timothy,
On Thu, Nov 7, 2013 at 12:33 PM, gettimothy gettimothy@zoho.com wrote:
Eliot,
Thank you so much for the reply.
Currently my low-level skills are atrophied and have organized my work-life to devote study time to regaining and improving them. This is a great opportunity to contribute and get my chops up in the process.
When you refer to 'machine code' and 'machine organization' do you mean the Cog/Squeak VM's or the AMD 64 instruction set? (I lack both, but if you mean the VM, a good exercise in learning it would be writing some good documentation on it)
I mean good low-level programming skills. Knowing how stacks and address spaces are organized, what the machine's calling convention is, what a system call looks like, etc, and what the current processor's instruction set is, it's theory etc (is it a RISC or a CISC; does it have delay slots, etc, etc).
So first things first. Get the stack VM wokring in 64-bits.
From your reply, I guess I would best be of use getting the Stack VM working in 64 bits--its something I am currently attempting to do.
I have a tri-boot machine--Windows 7, Linux with 32 bit compat libs--where I can run smalltalk, and a pure 64 bit boot, where I cannot run smalltalk.
OK, but right now you'll want to be in Smalltalk, and for quite a while.
I am currently attempting to get the source code from http://www.squeakvm.org/squeak64/ Squeak-3.8a-2.src.tar.gz to compile on the pure 64 box. The Quick Start steps failed, so I am now setting about studying the source code in merge64/platforms/unix/vm/sqUnixMain.c as it looks like the entry point for the VM. In the back of my mind, I am wondering if this is even the right approach to take..
It's not :-).
What do you think is the best approach to take?
Read the latest two articles on my blog (A Spur gear for Coghttp://www.mirandabanda.org/cogblog/2013/09/05/a-spur-gear-for-cog/ & Lazy Becomehttp://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-and-a-partial-read-barrier/ ). Make a VMMaker image (see e.g. Cog Blog :: Building a Cog Development Imagehttp://www.google.com/url?sa=t&rct=j&q=create%20a%20cog%20vmmaker%20image&source=web&cd=1&cad=rja&ved=0CCsQFjAA&url=http%3A%2F%2Fwww.mirandabanda.org%2Fcogblog%2Fbuild-image%2F&ei=sQp8UsnDL8GLjALn6oDICQ&usg=AFQjCNHoDMjPg2Sy7huxuOSDrTIyHo_RNw&sig2=s3vx6j1rl73gdHq37BMiiQ&bvm=bv.56146854,d.cGE ). Then read SpurMemoryManager, /especially/ its class comment. Then read its subclasses Spur32BitMemoryManager (functional) & Spur64BitMemoryManager (completely untested). Then read SpurBootstrap32. Try and create a 32-bit Spur image and run it. Then try and implement SpurBootstrap64. Try and create a 64-bit Spur image and run it.
This is /lots/ of work. In particular the last two steps require some significant design. So start slowly and see how you get on.
Cordially,
t
---- On Thu, 07 Nov 2013 10:54:01 -0800 *Eliot Miranda<eliot.miranda@gmail.com eliot.miranda@gmail.com>* wrote ----
Hi Timothy,
On Thu, Nov 7, 2013 at 7:02 AM, gettimothy gettimothy@zoho.com wrote:
Is there any chance Cog could be made to run on AMD64 natively without 32 bit libs?
Yes, that's a goal of my current work. Spur has a common object representation between 32- and 64-bits. Getting to a native Stack VM on AMD64 should be straight-forward. Getting to a Cog VM on AMD64 also requires writing a code generator for AMD64. That's actually a fun project. It involves configuring a Bochs plugin for an AMD64/IA32 simulator, and then writing a CogIA64Compiler subclass of CogAbstractInstruction.
If so, I would like to help out with whoever takes up this task. I would need direction, however as I have been do app development for too many years and my sys skills are atrophied.
How strong are your low-level skills? You'll need to be quite familiar with machine code, basic machine organization, etc. If you're not then you could instead have a go at getting the Stack VM working in 64-bits, and that would involve getting the 64-bit VM simulator working in VMMaker.
It will be great to have another collaborator!
t.
---- On Thu, 07 Nov 2013 06:01:00 -0800 *Bob Arning<arning315@comcast.net arning315@comcast.net>* wrote ----
It's absolutely none of my business what tools others choose to use, but I will say this:
Having more of this process in Smalltalk and less in other (arcane) languages increases the confidence that, should we lose someone's services, others could step up to fill the gap.
Cheers, Bob
On 11/7/13 8:28 AM, Igor Stasenko wrote:
Ec7Xf8-DaANjijv1beYiqxBApPntNg@mail.gmail.com" type="cite">
On 7 November 2013 08:58, Tobias Pape Das.Linux@gmx.de wrote:
Hey Tim and all, On 07.11.2013, at 05:00, Ron Teitelbaum ron@usmedrec.com wrote:
Hey Tim,
Göran and Eliot have been discussing this. I just talked to Eliot about
it
yesterday. He said he was happy to support cmake but didn't want to
have to
do the work himself. I'm hoping that the work Göran is doing on this now can be turned over to Eliot when it is finished. I think there is
agreement
that combining the excellent work of pharo build with Eliot's new vm
work is
a very good thing to do. The work to merge the build environments is already being done at 3D ICC. We are working on this for the Mac also
but
have not discussed it with Ian yet.
Ron Teitelbaum
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of tim Rowledge Sent: Wednesday, November 06, 2013 9:04 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build
process
Wow, no interest? Is it because make is painful or because nobody needs
to
make any more money?
I actually have interest but I am currently reluctant, for time-capturing reasons in my personal and work life.
However, Here is what I would do:
• Start from Ians CMake work, and try to generalize it for the non-Linux platforms • Windows would be kind-of straight-forward, • For OS X, I would really want to have the Cocoa-based VM stuff (aka Squeak VM 5.4.7.x) integrated and proper Xcode files generated, especially to be able to have iOS VMs built automatically. Here, some information from John McIntosh would be helpfull, especially a simple walk-through. I have some experience with that[1]
Despite all admiration I have for the way the PharoVM is built, there is one thing that bothers me: • You first somehow generate the VM sources (which is fine, and the automated way is amazing) • THEN, the a Script generates CMake-Files • CMake then generates Makefiles • and then finally a vm is compiled. This is one generating step too much, for my taste. Personally, I'd prefer CMake to just pick up the C-files generated by VMMaker, so that adding a new platform does not need to change the VMMaker…
The main big issue with 'platform-neutral' static source files, that they tend to grow with tons of #ifdef-s over time, reducing readability and creating a mess.
My point is that one or another way you have to deal with platform differences, and the way how i prefer to do it is using smalltalk code, but not .m4 files, or .cmake files, or writing a medium novel long configuration files using strange (better to say weird) scripting DSL. I can express all build process logic in smalltalk, which does not lessens the amount of work to deal with all platform nuances and dependencies etc, but at least it allows me to organize and shape it into some manageable form, which is easy to change & learn.
And another difference is, that i prefer working with browser & classes than with dozens of directories and files lying here and there.
But sure thing, it is a question of taste. If you prefer to maintain this:
MACRO (INTERNAL_PLUGIN plugin) SET (plugin_sources "") IF (DEFINED ${plugin}_sources) SET (plugin_sources ${${plugin}_sources}) ELSE (DEFINED ${plugin}_sources) FOREACH (dir ${src}/vm/intplugins ${cross}/plugins ${unix}/plugins) SET (tmp "") AUX_SOURCE_DIRECTORY (${dir}/${plugin} tmp) STRING_APPEND (plugin_sources "${tmp}") ENDFOREACH (dir) ENDIF (DEFINED ${plugin}_sources) IF (DEFINED ${plugin}_extra_sources) STRING_APPEND (plugin_sources "${${plugin}_extra_sources}") ENDIF (DEFINED ${plugin}_extra_sources) FILE (WRITE ${bld}/${plugin}/CMakeLists.in "") FOREACH (dir ${unix}/plugins ${unix}) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${dir}/${plugin}/build.cmake) ENDFOREACH (dir) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${config}/PluginInternal.cmake) CONFIGURE_FILE (${bld}/${plugin}/CMakeLists.in ${bld}/${plugin}/CMakeLists.txt @ONLY) ADD_SUBDIRECTORY (${bld}/${plugin} ${bld}/${plugin}) ENDMACRO (INTERNAL_PLUGIN)
And/or this:
AC_INIT([config.h.in])
SVNREV=`grep '$Rev: ' ${srcdir}/../../../platforms/Cross/vm/sqSCCSVersion.h \ | sed 's/.*$Rev: ([[0-9]][[0-9]]*).*/\1/'` AC_VM_VERSION(4,0,${SVNREV},4,2,0)
topdir=`cd ${srcdir}/../../..; pwd` cfgdir=`cd ${srcdir}; pwd`
AC_ARG_WITH(src, [ --with-src=dir generated src directory [default=src]], [ vmmsrc="${with_src}"], [ vmmsrc="src"])
vmmdir="${topdir}/${vmmsrc}"
if test ! -d "${topdir}/${vmmsrc}"; then if test -d "${topdir}/platforms/unix/${vmmsrc}"; then vmmdir="${topdir}/platforms/unix/${vmmsrc}" AC_MSG_RESULT([using built-in src directory]) fi fi
AC_MSG_RESULT(${vmmdir})
blddir=`pwd`
AC_ARG_WITH(vmmcfg, [ --with-vmmcfg=dir vm configuration directory containing plugins.int and plugins.ext [default=.]], [ vmmcfg="${with-vmmcfg}"], [ vmmcfg="${blddir}"])
# Compiling a Cogit VM or not? If so, need a cogit$o, cointerp, etc.
AC_ARG_ENABLE(cogit, [ --enable-cogit compile a cogit VM [default=yes]], cogit="no", cogit="yes") AC_SUBST(cogit)
#AC_ARG_ENABLE(jit, #[ --enable-jit enable J4 support [default=no]], #JIT="yes", JIT="no") # #test $JIT = "yes" && J_CFLAGS="-DJ_ENABLED" #AC_SUBST(J_CFLAGS)
# Check the generated src dir looks sane
AC_CHECK_VMM_DIR
AC_SUBST(topdir) AC_SUBST(cfgdir) AC_SUBST(vmmdir) AC_SUBST(vmmcfg) AC_SUBST(blddir)
SQ_VERSION=${SQ_MAJOR}.${SQ_MINOR}-${SQ_UPDATE}
AC_DEFINE_UNQUOTED(SQ_VERSION, "${SQ_VERSION}")
AC_SUBST(SQ_MAJOR) AC_SUBST(SQ_MINOR) AC_SUBST(SQ_UPDATE) AC_SUBST(SQ_VERSION)
VM_VERSION=${VM_MAJOR}.${VM_MINOR}-${VM_RELEASE}
AC_DEFINE_UNQUOTED(VM_VERSION, "${VM_VERSION}")
AC_SUBST(VM_MAJOR) AC_SUBST(VM_MINOR) AC_SUBST(VM_RELEASE) AC_SUBST(VM_VERSION)
# libdir contains ${exec_prefix}, so we have to default and expand early test "x$prefix" = xNONE && prefix=$ac_default_prefix test "x$exec_prefix" = xNONE && exec_prefix='${prefix}' imgdir=`eval echo ${libdir}/squeak` expanded_relative_imgdir=`eval echo lib/squeak/${VM_VERSION}` plgdir='${imgdir}/'`eval echo ${VM_VERSION}`
AC_SUBST(imgdir) AC_SUBST(expanded_relative_imgdir) AC_SUBST(plgdir)
AC_DEFINE(OS_TYPE, "unix")
AC_CANONICAL_HOST
host_cpu=`echo $host | sed 's,-.*,,'` host=`echo $host | sed 's,-unknown,,'`
AC_SUBST(host) AC_SUBST(host_cpu) AC_SUBST(host_vendor) AC_SUBST(host_os)
instead of plain smalltalk code, it is up to you.
But that's about 'too much' for my taste.
But if the community is positive to just move to the Pharo way of building VMs, I'd be fine with that, since that would unify a lot of infrastructure :)
Best -Tobias
[1] https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake
-- Best regards, Igor Stasenko.
-- best, Eliot
-- best, Eliot
Thanks.
I took a gander at Spur--very challenging and new, lots to learn.
Just what the doctor ordered
(:
t
---- On Thu, 07 Nov 2013 16:18:35 -0800 Eliot Miranda<eliot.miranda@gmail.com> wrote ----
On Thu, Nov 7, 2013 at 3:16 PM, gettimothy <gettimothy@zoho.com> wrote: Eliot,
Re "I mean good low-level programming skills. Knowing how stacks and address spaces are organized, what the machine's calling convention is, what a system call looks like, etc, and what the current processor's instruction set is, it's theory etc (is it a RISC or a CISC; does it have delay slots, etc, etc)."
Would an updated edition of Patterson and Hennessy be helpful here? My copy (like my c skills) is from 1993.
nothing fundamental that affects Cog has changed in that time... it'll do just fine.
t.
---- On Thu, 07 Nov 2013 13:54:03 -0800 Eliot Miranda<eliot.miranda@gmail.com> wrote ----
Hi Timothy, On Thu, Nov 7, 2013 at 12:33 PM, gettimothy <gettimothy@zoho.com> wrote: Eliot,
Thank you so much for the reply.
Currently my low-level skills are atrophied and have organized my work-life to devote study time to regaining and improving them. This is a great opportunity to contribute and get my chops up in the process.
When you refer to 'machine code' and 'machine organization' do you mean the Cog/Squeak VM's or the AMD 64 instruction set? (I lack both, but if you mean the VM, a good exercise in learning it would be writing some good documentation on it)
I mean good low-level programming skills. Knowing how stacks and address spaces are organized, what the machine's calling convention is, what a system call looks like, etc, and what the current processor's instruction set is, it's theory etc (is it a RISC or a CISC; does it have delay slots, etc, etc).
So first things first. Get the stack VM wokring in 64-bits.
From your reply, I guess I would best be of use getting the Stack VM working in 64 bits--its something I am currently attempting to do.
I have a tri-boot machine--Windows 7, Linux with 32 bit compat libs--where I can run smalltalk, and a pure 64 bit boot, where I cannot run smalltalk.
OK, but right now you'll want to be in Smalltalk, and for quite a while.
I am currently attempting to get the source code from http://www.squeakvm.org/squeak64/ Squeak-3.8a-2.src.tar.gz to compile on the pure 64 box. The Quick Start steps failed, so I am now setting about studying the source code in merge64/platforms/unix/vm/sqUnixMain.c as it looks like the entry point for the VM. In the back of my mind, I am wondering if this is even the right approach to take..
It's not :-).
What do you think is the best approach to take?
Read the latest two articles on my blog (A Spur gear for Cog & Lazy Become). Make a VMMaker image (see e.g. Cog Blog :: Building a Cog Development Image). Then read SpurMemoryManager, /especially/ its class comment. Then read its subclasses Spur32BitMemoryManager (functional) & Spur64BitMemoryManager (completely untested). Then read SpurBootstrap32. Try and create a 32-bit Spur image and run it. Then try and implement SpurBootstrap64. Try and create a 64-bit Spur image and run it.
This is /lots/ of work. In particular the last two steps require some significant design. So start slowly and see how you get on.
Cordially,
t
---- On Thu, 07 Nov 2013 10:54:01 -0800 Eliot Miranda<eliot.miranda@gmail.com> wrote ----
Hi Timothy,
On Thu, Nov 7, 2013 at 7:02 AM, gettimothy <gettimothy@zoho.com> wrote: Is there any chance Cog could be made to run on AMD64 natively without 32 bit libs?
Yes, that's a goal of my current work. Spur has a common object representation between 32- and 64-bits. Getting to a native Stack VM on AMD64 should be straight-forward. Getting to a Cog VM on AMD64 also requires writing a code generator for AMD64. That's actually a fun project. It involves configuring a Bochs plugin for an AMD64/IA32 simulator, and then writing a CogIA64Compiler subclass of CogAbstractInstruction.
If so, I would like to help out with whoever takes up this task. I would need direction, however as I have been do app development for too many years and my sys skills are atrophied.
How strong are your low-level skills? You'll need to be quite familiar with machine code, basic machine organization, etc. If you're not then you could instead have a go at getting the Stack VM working in 64-bits, and that would involve getting the 64-bit VM simulator working in VMMaker.
It will be great to have another collaborator!
t.
---- On Thu, 07 Nov 2013 06:01:00 -0800 Bob Arning<arning315@comcast.net> wrote ----
It's absolutely none of my business what tools others choose to use, but I will say this:
Having more of this process in Smalltalk and less in other (arcane) languages increases the confidence that, should we lose someone's services, others could step up to fill the gap.
Cheers, Bob
On 11/7/13 8:28 AM, Igor Stasenko wrote:
Ec7Xf8-DaANjijv1beYiqxBApPntNg@mail.gmail.com" type="cite">
On 7 November 2013 08:58, Tobias Pape <Das.Linux@gmx.de> wrote: Hey Tim and all, On 07.11.2013, at 05:00, Ron Teitelbaum <ron@usmedrec.com> wrote:
> Hey Tim, > > Göran and Eliot have been discussing this. I just talked to Eliot about it > yesterday. He said he was happy to support cmake but didn't want to have to > do the work himself. I'm hoping that the work Göran is doing on this now > can be turned over to Eliot when it is finished. I think there is agreement > that combining the excellent work of pharo build with Eliot's new vm work is > a very good thing to do. The work to merge the build environments is > already being done at 3D ICC. We are working on this for the Mac also but > have not discussed it with Ian yet. > > Ron Teitelbaum > >> -----Original Message----- >> From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- >> bounces@lists.squeakfoundation.org] On Behalf Of tim Rowledge >> Sent: Wednesday, November 06, 2013 9:04 PM >> To: The general-purpose Squeak developers list >> Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build > process >> >> >> Wow, no interest? Is it because make is painful or because nobody needs to >> make any more money?
I actually have interest but I am currently reluctant, for time-capturing reasons in my personal and work life.
However, Here is what I would do:
• Start from Ians CMake work, and try to generalize it for the non-Linux platforms • Windows would be kind-of straight-forward, • For OS X, I would really want to have the Cocoa-based VM stuff (aka Squeak VM 5.4.7.x) integrated and proper Xcode files generated, especially to be able to have iOS VMs built automatically. Here, some information from John McIntosh would be helpfull, especially a simple walk-through. I have some experience with that[1]
Despite all admiration I have for the way the PharoVM is built, there is one thing that bothers me: • You first somehow generate the VM sources (which is fine, and the automated way is amazing) • THEN, the a Script generates CMake-Files • CMake then generates Makefiles • and then finally a vm is compiled. This is one generating step too much, for my taste. Personally, I'd prefer CMake to just pick up the C-files generated by VMMaker, so that adding a new platform does not need to change the VMMaker…
The main big issue with 'platform-neutral' static source files, that they tend to
grow with tons of #ifdef-s over time, reducing readability and creating a mess.
My point is that one or another way you have to deal with platform differences,
and the way how i prefer to do it is using smalltalk code,
but not .m4 files, or .cmake files, or writing a medium novel long configuration files
using strange (better to say weird) scripting DSL.
I can express all build process logic in smalltalk, which does not lessens the amount of work to deal with all platform nuances and dependencies etc, but at least it allows me to organize and shape it into some manageable form, which is easy to change & learn.
And another difference is, that i prefer working with browser & classes than with dozens of directories and files lying here and there.
But sure thing, it is a question of taste. If you prefer to maintain this: ------------------------- MACRO (INTERNAL_PLUGIN plugin) SET (plugin_sources "") IF (DEFINED ${plugin}_sources) SET (plugin_sources ${${plugin}_sources}) ELSE (DEFINED ${plugin}_sources) FOREACH (dir ${src}/vm/intplugins ${cross}/plugins ${unix}/plugins) SET (tmp "") AUX_SOURCE_DIRECTORY (${dir}/${plugin} tmp) STRING_APPEND (plugin_sources "${tmp}") ENDFOREACH (dir) ENDIF (DEFINED ${plugin}_sources) IF (DEFINED ${plugin}_extra_sources) STRING_APPEND (plugin_sources "${${plugin}_extra_sources}") ENDIF (DEFINED ${plugin}_extra_sources) FILE (WRITE ${bld}/${plugin}/CMakeLists.in "") FOREACH (dir ${unix}/plugins ${unix}) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${dir}/${plugin}/build.cmake) ENDFOREACH (dir) FILE_APPEND (${bld}/${plugin}/CMakeLists.in ${config}/PluginInternal.cmake) CONFIGURE_FILE (${bld}/${plugin}/CMakeLists.in ${bld}/${plugin}/CMakeLists.txt @ONLY) ADD_SUBDIRECTORY (${bld}/${plugin} ${bld}/${plugin}) ENDMACRO (INTERNAL_PLUGIN) --------------------------
And/or this: -------------------------- AC_INIT([config.h.in])
SVNREV=`grep '$Rev: ' ${srcdir}/../../../platforms/Cross/vm/sqSCCSVersion.h \ | sed 's/.*$Rev: ([[0-9]][[0-9]]*).*/\1/'` AC_VM_VERSION(4,0,${SVNREV},4,2,0)
topdir=`cd ${srcdir}/../../..; pwd` cfgdir=`cd ${srcdir}; pwd`
AC_ARG_WITH(src, [ --with-src=dir generated src directory [default=src]], [ vmmsrc="${with_src}"], [ vmmsrc="src"])
vmmdir="${topdir}/${vmmsrc}"
if test ! -d "${topdir}/${vmmsrc}"; then if test -d "${topdir}/platforms/unix/${vmmsrc}"; then vmmdir="${topdir}/platforms/unix/${vmmsrc}" AC_MSG_RESULT([using built-in src directory]) fi fi
AC_MSG_RESULT(${vmmdir})
blddir=`pwd`
AC_ARG_WITH(vmmcfg, [ --with-vmmcfg=dir vm configuration directory containing plugins.int and plugins.ext [default=.]], [ vmmcfg="${with-vmmcfg}"], [ vmmcfg="${blddir}"])
# Compiling a Cogit VM or not? If so, need a cogit$o, cointerp, etc.
AC_ARG_ENABLE(cogit, [ --enable-cogit compile a cogit VM [default=yes]], cogit="no", cogit="yes") AC_SUBST(cogit)
#AC_ARG_ENABLE(jit, #[ --enable-jit enable J4 support [default=no]], #JIT="yes", JIT="no") # #test $JIT = "yes" && J_CFLAGS="-DJ_ENABLED" #AC_SUBST(J_CFLAGS)
# Check the generated src dir looks sane
AC_CHECK_VMM_DIR
AC_SUBST(topdir) AC_SUBST(cfgdir) AC_SUBST(vmmdir) AC_SUBST(vmmcfg) AC_SUBST(blddir)
SQ_VERSION=${SQ_MAJOR}.${SQ_MINOR}-${SQ_UPDATE}
AC_DEFINE_UNQUOTED(SQ_VERSION, "${SQ_VERSION}")
AC_SUBST(SQ_MAJOR) AC_SUBST(SQ_MINOR) AC_SUBST(SQ_UPDATE) AC_SUBST(SQ_VERSION)
VM_VERSION=${VM_MAJOR}.${VM_MINOR}-${VM_RELEASE}
AC_DEFINE_UNQUOTED(VM_VERSION, "${VM_VERSION}")
AC_SUBST(VM_MAJOR) AC_SUBST(VM_MINOR) AC_SUBST(VM_RELEASE) AC_SUBST(VM_VERSION)
# libdir contains ${exec_prefix}, so we have to default and expand early test "x$prefix" = xNONE && prefix=$ac_default_prefix test "x$exec_prefix" = xNONE && exec_prefix='${prefix}' imgdir=`eval echo ${libdir}/squeak` expanded_relative_imgdir=`eval echo lib/squeak/${VM_VERSION}` plgdir='${imgdir}/'`eval echo ${VM_VERSION}`
AC_SUBST(imgdir) AC_SUBST(expanded_relative_imgdir) AC_SUBST(plgdir)
AC_DEFINE(OS_TYPE, "unix")
AC_CANONICAL_HOST
host_cpu=`echo $host | sed 's,-.*,,'` host=`echo $host | sed 's,-unknown,,'`
AC_SUBST(host) AC_SUBST(host_cpu) AC_SUBST(host_vendor) AC_SUBST(host_os) ----------------------------
instead of plain smalltalk code, it is up to you.
But that's about 'too much' for my taste.
But if the community is positive to just move to the Pharo way of building VMs, I'd be fine with that, since that would unify a lot of infrastructure :)
Best -Tobias
[1] https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake
-- Best regards, Igor Stasenko.
Part 4 of the Blue Book--chapter 26 The implementation--in the intro there is this example:
center ^ origin + corner / 2
With these operations
Rectangle center 0 push the value of the receiver's first instance variable (origin) onto the stack 1 push the value of the receiver's second instance variable (corner) onto the stack 176 send a binary message with the selector + 119 push the Smalllnteger 2 onto the stack 185 send a binary message with the selector / 124 return the object on top of the stack as the value of the message (center)
In a Workspace, when I doit on 3 + 7/2 I get 5, left, right, unary, binary....rules apply.
What I see here--and please check my reasoning--is a RPN that places things onto the stack via Smalltalk's order of operation rules and then does conventional RPN processing.
In other words, Smalltalk expressions are translated to RPN and then placed on the stack.
A simple 'banish the thought' or 'yep' or 'sometimes' would be helpful as I move forward in my study. I am just trying to avoid carrying forward an improper idea that I will have to revise later when/if the facts turn out otherwise.
thx.
t
On 19 November 2013 16:33, gettimothy gettimothy@zoho.com wrote:
Part 4 of the Blue Book--chapter 26 The implementation--in the intro there is this example:
center ^ origin + corner / 2
With these operations
Rectangle center 0 push the value of the receiver's first instance variable (origin) onto the stack 1 push the value of the receiver's second instance variable (corner) onto the stack 176 send a binary message with the selector + 119 push the Smalllnteger 2 onto the stack 185 send a binary message with the selector / 124 return the object on top of the stack as the value of the message (center)
In a Workspace, when I doit on 3 + 7/2 I get 5, left, right, unary, binary....rules apply.
Yep, because "message sending is all there is", which equates here to a lack of operator precedence. So "3 + 7/2" means "(3 + 7) / 2".
+ and / here are known as binary selectors.
What I see here--and please check my reasoning--is a RPN that places things onto the stack via Smalltalk's order of operation rules and then does conventional RPN processing.
More generally, keyword sends take precedence over unary sends which take precedence over binary selectors. So in
foo something: 1 + 2 negated with: bar
the #negated message will be sent to the object 2, that will be the argument of the #+ message, sent to the object 1, and then that result and the object bar will be the arguments of the #something:with: message to the foo object.
frank
In other words, Smalltalk expressions are translated to RPN and then placed on the stack.
A simple 'banish the thought' or 'yep' or 'sometimes' would be helpful as I move forward in my study. I am just trying to avoid carrying forward an improper idea that I will have to revise later when/if the facts turn out otherwise.
thx.
t
Hi Timothy,
On Tue, Nov 19, 2013 at 8:33 AM, gettimothy gettimothy@zoho.com wrote:
Part 4 of the Blue Book--chapter 26 The implementation--in the intro there is this example:
center ^ origin + corner / 2
With these operations
Rectangle center 0 push the value of the receiver's first instance variable (origin) onto the stack 1 push the value of the receiver's second instance variable (corner) onto the stack 176 send a binary message with the selector + 119 push the Smalllnteger 2 onto the stack 185 send a binary message with the selector / 124 return the object on top of the stack as the value of the message (center)
In a Workspace, when I doit on 3 + 7/2 I get 5, left, right, unary, binary....rules apply.
What I see here--and please check my reasoning--is a RPN that places things onto the stack via Smalltalk's order of operation rules and then does conventional RPN processing.
In other words, Smalltalk expressions are translated to RPN and then placed on the stack.
Yes, and so they are in most stack-based implementations of languages. Bytecode for a stack machine is a form of RPN.
A simple 'banish the thought' or 'yep' or 'sometimes' would be helpful as
I move forward in my study. I am just trying to avoid carrying forward an improper idea that I will have to revise later when/if the facts turn out otherwise.
thx.
t
Eliot and Frank,
Thank you.
---- On Tue, 19 Nov 2013 08:47:00 -0800 Eliot Miranda<eliot.miranda@gmail.com> wrote ----
Hi Timothy,
On Tue, Nov 19, 2013 at 8:33 AM, gettimothy <gettimothy@zoho.com> wrote: Part 4 of the Blue Book--chapter 26 The implementation--in the intro there is this example:
center ^ origin + corner / 2
With these operations
Rectangle center 0 push the value of the receiver's first instance variable (origin) onto the stack 1 push the value of the receiver's second instance variable (corner) onto the stack 176 send a binary message with the selector + 119 push the Smalllnteger 2 onto the stack 185 send a binary message with the selector / 124 return the object on top of the stack as the value of the message (center)
In a Workspace, when I doit on 3 + 7/2 I get 5, left, right, unary, binary....rules apply.
What I see here--and please check my reasoning--is a RPN that places things onto the stack via Smalltalk's order of operation rules and then does conventional RPN processing.
In other words, Smalltalk expressions are translated to RPN and then placed on the stack.
Yes, and so they are in most stack-based implementations of languages. Bytecode for a stack machine is a form of RPN.
A simple 'banish the thought' or 'yep' or 'sometimes' would be helpful as I move forward in my study. I am just trying to avoid carrying forward an improper idea that I will have to revise later when/if the facts turn out otherwise.
thx.
t
While upgrading my Slackware to 14.1 so I could install Bochs and re-compiling my apps I saw that esr's gpsd requires something called scons for its build system:
Here is an example from the docs:
Here's the famous "Hello, World!" program in C: int main() { printf("Hello, world!\n"); } And here's how to build it using SCons. Enter the following into a file named SConstruct: Program('hello.c') This minimal configuration file gives SCons two pieces of information: what you want to build (an executable program), and the input file from which you want it built (the hello.c file). Program is a builder_method, a Python call that tells SCons that you want to build an executable program. That's it. Now run the scons command to build the program. On a POSIX-compliant system like Linux or UNIX, you'll see something like: % scons scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... cc -o hello.o -c hello.c cc -o hello hello.o scons: done building targets. On a Windows system with the Microsoft Visual C++ compiler, you'll see something like: C:>scons scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... cl /Fohello.obj /c hello.c /nologo link /nologo /OUT:hello.exe hello.obj embedManifestExeCheck(target, source, env) scons: done building targets. Has anybody poked around this thing?
tty
I've used both scons and its re-write waf.
I consider them to be the true "next generation" build tools. As far ahead of all the various "make" flavors as git and hg are ahead of cvs.
They both have decent docs and user communities, but there is a bit of a learning curve :(.
On 13-11-28 17:47 , gettimothy wrote:
While upgrading my Slackware to 14.1 so I could install Bochs and re-compiling my apps I saw that esr's gpsd requires something called scons for its build system:
Here is an example from the docs:
Here's the famous "Hello, World!" program in C: int main() { printf("Hello, world!\n"); } And here's how to build it using SCons. Enter the following into a file named SConstruct: Program('hello.c') This minimal configuration file gives SCons two pieces of information: what you want to build (an executable program), and the input file from which you want it built (the hello.c file). Program is a builder_method, a Python call that tells SCons that you want to build an executable program. That's it. Now run the scons command to build the program. On a POSIX-compliant system like Linux or UNIX, you'll see something like: % scons scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... cc -o hello.o -c hello.c cc -o hello hello.o scons: done building targets. On a Windows system with the Microsoft Visual C++ compiler, you'll see something like: C:>scons scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... cl /Fohello.obj /c hello.c /nologo link /nologo /OUT:hello.exe hello.obj embedManifestExeCheck(target, source, env) scons: done building targets. Has anybody poked around this thing?
Not I. Do you have specific questions?
tty
Regards,
Thanks, Tom
I watched a video a while ago where VisualWorks had an object for an .ini file.
I have also seen interest to move the build system into the Smalltalk environment itself.
I saw Program{'hello.c'} and thought "SomeAppropriatelyNamedSmalltalkClass generateBuildSystem platform: #pdp11 ...."
I will re-adress this when I can get the Stack VM running and get a handle on the present build system.
Cordially,
tty
---- On Fri, 29 Nov 2013 11:32:56 -0800 Tom Rushworth<tom.b.rushworth@gmail.com> wrote ----
I've used both scons and its re-write waf.
I consider them to be the true "next generation" build tools. As far ahead of all the various "make" flavors as git and hg are ahead of cvs.
They both have decent docs and user communities, but there is a bit of a learning curve :(.
On 13-11-28 17:47 , gettimothy wrote: > While upgrading my Slackware to 14.1 so I could install Bochs and re-compiling my apps I saw that esr's gpsd requires something called scons for its build system: > > http://www.scons.org > > Here is an example from the docs: > > > Here's the famous "Hello, World!" program in C: > int main() { printf("Hello, world!\n"); } And here's how to build it using SCons. Enter the following into a file named SConstruct: > Program('hello.c') This minimal configuration file gives SCons two pieces of information: what you want to build (an executable program), and the input file from which you want it built (the hello.c file). Program is a builder_method, a Python call that tells SCons that you want to build an executable program. > That's it. Now run the scons command to build the program. On a POSIX-compliant system like Linux or UNIX, you'll see something like: > % scons scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... cc -o hello.o -c hello.c cc -o hello hello.o scons: done building targets. On a Windows system with the Microsoft Visual C++ compiler, you'll see something like: > C:&gt;scons scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... cl /Fohello.obj /c hello.c /nologo link /nologo /OUT:hello.exe hello.obj embedManifestExeCheck(target, source, env) scons: done building targets. > Has anybody poked around this thing?
Not I. Do you have specific questions? > > tty > Regards,
On 30 November 2013 00:21, gettimothy gettimothy@zoho.com wrote:
Thanks, Tom
I watched a video a while ago where VisualWorks had an object for an .ini file.
I have also seen interest to move the build system into the Smalltalk environment itself.
I saw Program{'hello.c'} and thought "SomeAppropriatelyNamedSmalltalkClass generateBuildSystem platform: #pdp11 ...."
.. yes, and we have one:
PharoVMBuilder build
:)
I will re-adress this when I can get the Stack VM running and get a handle on the present build system.
Cordially,
tty
---- On Fri, 29 Nov 2013 11:32:56 -0800 *Tom Rushworth<tom.b.rushworth@gmail.com tom.b.rushworth@gmail.com>* wrote
I've used both scons and its re-write waf.
I consider them to be the true "next generation" build tools. As far ahead of all the various "make" flavors as git and hg are ahead of cvs.
They both have decent docs and user communities, but there is a bit of a learning curve :(.
On 13-11-28 17:47 , gettimothy wrote:
While upgrading my Slackware to 14.1 so I could install Bochs and
re-compiling my apps I saw that esr's gpsd requires something called scons for its build system:
Here is an example from the docs:
Here's the famous "Hello, World!" program in C: int main() { printf("Hello, world!\n"); } And here's how to build it
using SCons. Enter the following into a file named SConstruct:
Program('hello.c') This minimal configuration file gives SCons two
pieces of information: what you want to build (an executable program), and the input file from which you want it built (the hello.c file). Program is a builder_method, a Python call that tells SCons that you want to build an executable program.
That's it. Now run the scons command to build the program. On a
POSIX-compliant system like Linux or UNIX, you'll see something like:
% scons scons: Reading SConscript files ... scons: done reading
SConscript files. scons: Building targets ... cc -o hello.o -c hello.c cc -o hello hello.o scons: done building targets. On a Windows system with the Microsoft Visual C++ compiler, you'll see something like:
C:>scons scons: Reading SConscript files ... scons: done reading
SConscript files. scons: Building targets ... cl /Fohello.obj /c hello.c /nologo link /nologo /OUT:hello.exe hello.obj embedManifestExeCheck(target, source, env) scons: done building targets.
Has anybody poked around this thing?
Not I. Do you have specific questions?
tty
Regards,
-- Tom Rushworth
Eliot
First, if these discussion is inappropriate for squeak-dev, I have subscribed to squeak-vm-beginners and we can move it there or elsewhere if I am creating too much noise here.
In working the steps at http://www.mirandabanda.org/cogblog/build-image/ and I have found that running all the tests for the Alien install on the SqueakVM that comes with the all-in-one app fails all but one of its tests. (primitives fail)
If I start the image using the CogVM then all the tests pass.
So, is it correct to say that building a Cog Development Image on Squeak4.4 or greater depends on a pre-built CogVM from http://www.mirandabanda.org/files/Cog/VM/ ?
I am assuming yes, but I want to verify with you before I document what I am doing
thx.
t
On Fri, Nov 08, 2013 at 07:29:42AM -0800, gettimothy wrote:
Eliot
First, if these discussion is inappropriate for squeak-dev, I have subscribed to squeak-vm-beginners and we can move it there or elsewhere if I am creating too much noise here.
Hi Timothy,
The vm-dev list is here:
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/vm-dev
It is not a beginner's list, and your discussion would be welcome there. Either way, you are not creating "noise" and it is great to see you getting involved.
In working the steps at http://www.mirandabanda.org/cogblog/build-image/ and I have found that running all the tests for the Alien install on the SqueakVM that comes with the all-in-one app fails all but one of its tests. (primitives fail)
If I start the image using the CogVM then all the tests pass.
So, is it correct to say that building a Cog Development Image on Squeak4.4 or greater depends on a pre-built CogVM from http://www.mirandabanda.org/files/Cog/VM/ ?
I am assuming yes, but I want to verify with you before I document what I am doing
It is a good idea to use a VM from mirandaband.org, because different VMs may have different runtime behaviour, and using a runtime environment that matches Eliot's will prevent confusion.
Strictly speaking, you can build a Cog VM using pretty much any VM that works with your Squeak4.4 image. So no it is not necessary to use a specific pre-built image, but it is a very good idea to do so, especially during the time when you are first learning how to do VM building.
I think Eliot will give you a similar answer, so hopefully he won't mind me stepping in to answer some of your questions.
Dave
thx.
t
David,
Thank you. I have joined that list and will continue the conversation there.
Cordially,
t.
---- On Fri, 08 Nov 2013 08:12:51 -0800 David T. Lewis<lewis@mail.msen.com> wrote ----
On Fri, Nov 08, 2013 at 07:29:42AM -0800, gettimothy wrote: > Eliot > > First, if these discussion is inappropriate for squeak-dev, I have subscribed to squeak-vm-beginners and we can move it there or elsewhere if I am creating too much noise here. >
Hi Timothy,
The vm-dev list is here:
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/vm-dev
It is not a beginner's list, and your discussion would be welcome there. Either way, you are not creating "noise" and it is great to see you getting involved.
> In working the steps at http://www.mirandabanda.org/cogblog/build-image/ and I have found that running all the tests for the Alien install on the SqueakVM that comes with the all-in-one app fails all but one of its tests. (primitives fail) > > If I start the image using the CogVM then all the tests pass. > > So, is it correct to say that building a Cog Development Image on Squeak4.4 or greater depends on a pre-built CogVM from http://www.mirandabanda.org/files/Cog/VM/ ? > > I am assuming yes, but I want to verify with you before I document what I am doing >
It is a good idea to use a VM from mirandaband.org, because different VMs may have different runtime behaviour, and using a runtime environment that matches Eliot's will prevent confusion.
Strictly speaking, you can build a Cog VM using pretty much any VM that works with your Squeak4.4 image. So no it is not necessary to use a specific pre-built image, but it is a very good idea to do so, especially during the time when you are first learning how to do VM building.
I think Eliot will give you a similar answer, so hopefully he won't mind me stepping in to answer some of your questions.
Dave
> thx. > > t >
So, how’s the bounty Hunting going? Been a bit quiet.
I see the cleanups for the plugin code arrangement and they are good. I think. I’d really like to see the full solution to my problem sometime soon so I can send MONEY to someone. Just think of it; $1000 will get you a nice iPad Air and plenty left over to fill it with books or music or apps.
Or, if it turns out a bunch of people get together to solve the problem, I can happily split the dosh, or even make it a donation to squeak foundation or pharo foundation as appropriate.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum immane mittam = I have a catapult. Give me all the money, or I will fling an enormous rock at your head.
Yeah, I want Smalltalk to run the platform C compiler and so on directly, through OSProcess or equivalent. I've had quite enough of cmake et al.
-C
-- Craig Latta www.netjam.org/resume +1 510 984 8117 (Skype rings this until 31 January 2014)
Ian is also interested. If we can get everyone on the same page and with enough help it looks like we can make some progress.
I would also like to thank everyone that is working on the new build process. You guys are doing really great work!
I'm hopeful we can get to a place that makes it easier for everyone, in both communities.
All the best,
Ron Teitelbaum
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Craig Latta Sent: Thursday, November 07, 2013 10:22 AM To: squeak-dev@lists.squeakfoundation.org Subject: [squeak-dev] re: A Bounty for CMake-ifying stack/Cog vm build
process
Yeah, I want Smalltalk to run the platform C compiler and so on
directly,
through OSProcess or equivalent. I've had quite enough of cmake et al.
-C
-- Craig Latta www.netjam.org/resume +1 510 984 8117 (Skype rings this until 31 January 2014)
One important thing to remember is coping with a first build on a new machine. Having a squeak app that can drive cc to build a vm would be very neat, but if you don't yet have a working vm for a device you could be in trouble. An advantage of the cmake process is that it bypasses that issue. Actually running the configure on the target machine means you get (hopefully!) accurate results when querying facilities. There is also some benefit in a production environment in being able to pass a 'normal' build job to someone else without having to find a squeak buildomatic cognizant person.
Deployment should be regarded a separate problem than building.
On Thu, Nov 7, 2013 at 2:00 PM, tim Rowledge tim@rowledge.org wrote:
One important thing to remember is coping with a first build on a new machine. Having a squeak app that can drive cc to build a vm would be very neat, but if you don't yet have a working vm for a device you could be in trouble. An advantage of the cmake process is that it bypasses that issue. Actually running the configure on the target machine means you get (hopefully!) accurate results when querying facilities. There is also some benefit in a production environment in being able to pass a 'normal' build job to someone else without having to find a squeak buildomatic cognizant person.
But Tim's point still stands, because deployment is the problem you solve after having solved the "build it" problem :)
frank
On 7 November 2013 20:13, Chris Muller asqueaker@gmail.com wrote:
Deployment should be regarded a separate problem than building.
On Thu, Nov 7, 2013 at 2:00 PM, tim Rowledge tim@rowledge.org wrote:
One important thing to remember is coping with a first build on a new machine. Having a squeak app that can drive cc to build a vm would be very neat, but if you don't yet have a working vm for a device you could be in trouble. An advantage of the cmake process is that it bypasses that issue. Actually running the configure on the target machine means you get (hopefully!) accurate results when querying facilities. There is also some benefit in a production environment in being able to pass a 'normal' build job to someone else without having to find a squeak buildomatic cognizant person.
Well, I don't think Tim's point stands anyway. It assumes a blank OS on any machine can use configure and cmake, but not squeak. Can windows machines run configure and cmake out of the box?
Some sort of installation hurdle must be overcome, whether cygwin or new-squeak-based-builder.
People who are building VM's are a much smaller, more-technically capable group than those who need to deploy something (e.g., an application). If you design your deployment system for the former, it think it won't be useful to the latter.
On Thu, Nov 7, 2013 at 2:36 PM, Frank Shearar frank.shearar@gmail.comwrote:
But Tim's point still stands, because deployment is the problem you solve after having solved the "build it" problem :)
frank
On 7 November 2013 20:13, Chris Muller asqueaker@gmail.com wrote:
Deployment should be regarded a separate problem than building.
On Thu, Nov 7, 2013 at 2:00 PM, tim Rowledge tim@rowledge.org wrote:
One important thing to remember is coping with a first build on a new
machine. Having a squeak app that can drive cc to build a vm would be very neat, but if you don't yet have a working vm for a device you could be in trouble.
An advantage of the cmake process is that it bypasses that issue.
Actually running the configure on the target machine means you get (hopefully!) accurate results when querying facilities. There is also some benefit in a production environment in being able to pass a 'normal' build job to someone else without having to find a squeak buildomatic cognizant person.
Wait, why are we talking about deploying a Squeak application here? We're talking about taking a blank machine and being able to build a Squeak VM on it.
Tim's saying that you can't drive a C compiler from within the image on a machine for which no VM has ever been built, because there is no VM. ("Machine" here means a machine architecture, rather than, say, a fresh Ubuntu install.) You need a bootstrap. And configure/cmake/whatever happens to provide a very easy way to bootstrap to the first VM that can run an image that _can_ drive a C compiler to build the next gen VM.
frank
On 7 November 2013 20:45, Chris Muller ma.chris.m@gmail.com wrote:
Well, I don't think Tim's point stands anyway. It assumes a blank OS on any machine can use configure and cmake, but not squeak. Can windows machines run configure and cmake out of the box?
Some sort of installation hurdle must be overcome, whether cygwin or new-squeak-based-builder.
People who are building VM's are a much smaller, more-technically capable group than those who need to deploy something (e.g., an application). If you design your deployment system for the former, it think it won't be useful to the latter.
On Thu, Nov 7, 2013 at 2:36 PM, Frank Shearar frank.shearar@gmail.com wrote:
But Tim's point still stands, because deployment is the problem you solve after having solved the "build it" problem :)
frank
On 7 November 2013 20:13, Chris Muller asqueaker@gmail.com wrote:
Deployment should be regarded a separate problem than building.
On Thu, Nov 7, 2013 at 2:00 PM, tim Rowledge tim@rowledge.org wrote:
One important thing to remember is coping with a first build on a new machine. Having a squeak app that can drive cc to build a vm would be very neat, but if you don't yet have a working vm for a device you could be in trouble. An advantage of the cmake process is that it bypasses that issue. Actually running the configure on the target machine means you get (hopefully!) accurate results when querying facilities. There is also some benefit in a production environment in being able to pass a 'normal' build job to someone else without having to find a squeak buildomatic cognizant person.
On Thu, Nov 7, 2013 at 3:28 PM, Frank Shearar frank.shearar@gmail.comwrote:
Wait, why are we talking about deploying a Squeak application here? We're talking about taking a blank machine and being able to build a Squeak VM on it.
Tim's saying that you can't drive a C compiler from within the image on a machine for which no VM has ever been built, because there is no VM. ("Machine" here means a machine architecture, rather than, say, a fresh Ubuntu install.) You need a bootstrap. And configure/cmake/whatever happens to provide a very easy way to bootstrap to the first VM that can run an image that _can_ drive a C compiler to build the next gen VM.
Hm, ok. That's a pretty rarely-occurring event to be putting a lot thought into a framework for. I'm doubtful such a framework would ever "work the first time" on new platforms.
For building deployable packages on existing platforms, Igors words really resonated with me. I'll butt out now. :)
frank
On 7 November 2013 20:45, Chris Muller ma.chris.m@gmail.com wrote:
Well, I don't think Tim's point stands anyway. It assumes a blank OS on
any
machine can use configure and cmake, but not squeak. Can windows
machines
run configure and cmake out of the box?
Some sort of installation hurdle must be overcome, whether cygwin or new-squeak-based-builder.
People who are building VM's are a much smaller, more-technically capable group than those who need to deploy something (e.g., an application). If you design your deployment system for the former, it think it won't be useful to the latter.
On Thu, Nov 7, 2013 at 2:36 PM, Frank Shearar frank.shearar@gmail.com wrote:
But Tim's point still stands, because deployment is the problem you solve after having solved the "build it" problem :)
frank
On 7 November 2013 20:13, Chris Muller asqueaker@gmail.com wrote:
Deployment should be regarded a separate problem than building.
On Thu, Nov 7, 2013 at 2:00 PM, tim Rowledge tim@rowledge.org
wrote:
One important thing to remember is coping with a first build on a new machine. Having a squeak app that can drive cc to build a vm would
be very
neat, but if you don't yet have a working vm for a device you could
be in
trouble. An advantage of the cmake process is that it bypasses that issue. Actually running the configure on the target machine means you get (hopefully!) accurate results when querying facilities. There is
also some
benefit in a production environment in being able to pass a 'normal'
build
job to someone else without having to find a squeak buildomatic
cognizant
person.
On 7 November 2013 22:50, Chris Muller ma.chris.m@gmail.com wrote:
On Thu, Nov 7, 2013 at 3:28 PM, Frank Shearar frank.shearar@gmail.comwrote:
Wait, why are we talking about deploying a Squeak application here? We're talking about taking a blank machine and being able to build a Squeak VM on it.
Tim's saying that you can't drive a C compiler from within the image on a machine for which no VM has ever been built, because there is no VM. ("Machine" here means a machine architecture, rather than, say, a fresh Ubuntu install.) You need a bootstrap. And configure/cmake/whatever happens to provide a very easy way to bootstrap to the first VM that can run an image that _can_ drive a C compiler to build the next gen VM.
Hm, ok. That's a pretty rarely-occurring event to be putting a lot thought into a framework for. I'm doubtful such a framework would ever "work the first time" on new platforms.
For building deployable packages on existing platforms, Igors words really resonated with me. I'll butt out now. :)
Thanks for supportive words :)
For android, which does not supported by cmake Dimiry Golubovsky just managed to do it in a way how it can work: he wrote a configuration (in smalltalk) which generates files which compatible with android build infrastructure. I don't know the details, but you can always look at CMakeVMMaker-Android category in CMakeVMMaker package.
That means two things: - CMakeVMMaker despite its name actually does not means 'cmake only'. - the guy with little knowledge of android nuances (like me), can easily pick up this work and modify it in case of need.
What else i can say? If people for some reason don't like it, it would be stupid to force it upon them. The thing is there, open source, and everyone is welcome to use or abuse it.
So, if you don't like it, you're free to write own.. I informed that same work been done (and it works, works well). so rather than starting from scratch, i would twink twice, because i could take what's already done as a starting point and improve or change it (if i don't like something). So the decision whether to use it or write own from scratch is up to you, people. I'm out.
On 7 November 2013 21:36, Frank Shearar frank.shearar@gmail.com wrote:
But Tim's point still stands, because deployment is the problem you solve after having solved the "build it" problem :)
This is not an issue. You can always run VM on other machine, where it runs to generate config/source files, and then build VM on machine where VM don't runs yet. Not mentioning cross-compiling approach. And that technique already employed in pharo building for number of builds, like for iphone and android platforms. Even building ppa-distro for linux goes same way: its just takes configuration & sources (and all source files) generated by build server and built somewhere on other end of the world in linux ppa build farms.
frank
On 7 November 2013 20:13, Chris Muller asqueaker@gmail.com wrote:
Deployment should be regarded a separate problem than building.
On Thu, Nov 7, 2013 at 2:00 PM, tim Rowledge tim@rowledge.org wrote:
One important thing to remember is coping with a first build on a new
machine. Having a squeak app that can drive cc to build a vm would be very neat, but if you don't yet have a working vm for a device you could be in trouble.
An advantage of the cmake process is that it bypasses that issue.
Actually running the configure on the target machine means you get (hopefully!) accurate results when querying facilities. There is also some benefit in a production environment in being able to pass a 'normal' build job to someone else without having to find a squeak buildomatic cognizant person.
Hi Igor, hi list,
sorry for replying late,…
My reply was intended to stir the conversation a litte, to keep it going, which, I assume, it did. I really like your opinion, Igor :)
On 07.11.2013, at 14:28, Igor Stasenko siguctua@gmail.com wrote:
On 7 November 2013 08:58, Tobias Pape Das.Linux@gmx.de wrote: Hey Tim and all, On 07.11.2013, at 05:00, Ron Teitelbaum ron@usmedrec.com wrote:
Hey Tim,
Göran and Eliot have been discussing this. I just talked to Eliot about it yesterday. He said he was happy to support cmake but didn't want to have to do the work himself. I'm hoping that the work Göran is doing on this now can be turned over to Eliot when it is finished. I think there is agreement that combining the excellent work of pharo build with Eliot's new vm work is a very good thing to do. The work to merge the build environments is already being done at 3D ICC. We are working on this for the Mac also but have not discussed it with Ian yet.
Ron Teitelbaum
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of tim Rowledge Sent: Wednesday, November 06, 2013 9:04 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build
process
Wow, no interest? Is it because make is painful or because nobody needs to make any more money?
I actually have interest but I am currently reluctant, for time-capturing reasons in my personal and work life.
However, Here is what I would do:
• Start from Ians CMake work, and try to generalize it for the non-Linux platforms • Windows would be kind-of straight-forward, • For OS X, I would really want to have the Cocoa-based VM stuff (aka Squeak VM 5.4.7.x) integrated and proper Xcode files generated, especially to be able to have iOS VMs built automatically. Here, some information from John McIntosh would be helpfull, especially a simple walk-through. I have some experience with that[1]
Despite all admiration I have for the way the PharoVM is built, there is one thing that bothers me: • You first somehow generate the VM sources (which is fine, and the automated way is amazing) • THEN, the a Script generates CMake-Files • CMake then generates Makefiles • and then finally a vm is compiled. This is one generating step too much, for my taste. Personally, I'd prefer CMake to just pick up the C-files generated by VMMaker, so that adding a new platform does not need to change the VMMaker…
The main big issue with 'platform-neutral' static source files, that they tend to grow with tons of #ifdef-s over time, reducing readability and creating a mess.
My point is that one or another way you have to deal with platform differences, and the way how i prefer to do it is using smalltalk code, but not .m4 files, or .cmake files, or writing a medium novel long configuration files using strange (better to say weird) scripting DSL. I can express all build process logic in smalltalk, which does not lessens the amount of work to deal with all platform nuances and dependencies etc, but at least it allows me to organize and shape it into some manageable form, which is easy to change & learn.
And another difference is, that i prefer working with browser & classes than with dozens of directories and files lying here and there.
I did not want to imply we have to do it my way, not at all. And you are certainly right. Smalltalk is a good way to do things.
The only thing that got me thinking is, a lot of people use tools like CMake to drive build processes, and they know the edges of the domain very well. Building software can be quite complex: think Platforms, compiler quirks, SDK restrictions, cross compilations, to just name a few. CMake (even more than autotools) is quite good at these tasks, especially regarding the cross-platform part. If we now start to, effectively, reimplement CMake or autotools, we will run in the issues, those tools all have solved years ago. CMake even has beautiful output.
I think it would take an tremendous effort to get a Build tool that (only thinking of the Squeak/Pharo VM) • can build well with different compilers (Clang/Gcc, probably Microsoft) • can handle the platform-discovery (Linux, OSX, Windows, RISC!) • can handle library discovery (finding stuff like libuuid) • can do cross-compilation and the signing-stuff (iOS, perhaps android)
If we get this working, this would be amazing. I am a bit reluctant, it would be a lot of work for me…
But sure thing, it is a question of taste. If you prefer to maintain this:
[22 lines old CMAKE]
And/or this:
[96 lines autoconf/make/whatever]
instead of plain smalltalk code, it is up to you.
But that's about 'too much' for my taste.
I concur.
My impression is, we can choose from four “evils”[1]: 1. Accept the status quo. Painful for starters with its 8+ ways of doing essentially the same and every single one has some kind of big drawback. 2. Use CMake completely. Painful, because we have to maintain two bodies of knowledge, VMMaker and CMake. 3. Use cmake through CMakeVMMaker. Painful, because it can not fully benefit from Smalltalk nor from CMake. You have always to make up your mind whether to implement something on the Smalltalk or the CMake level 4. Have a Smalltalk-only build too. Painful, because it is going to take a lot of time.
I can accept any of them, but the first :) 2. and 3. have the benefits that they are already there, to certain degrees. (2. only in the Unix-vm part, done by Ian, 3. currently only used by the Pharo community)
How shall we as the VM community[2] decide?
Best -Tobias
[1] not really evil, only each painful to a certain degree [2] Who are we actually? • The Pharo and Squeak people, • The Cuis people • The Newspeak People • The CogVM people • Whom am I missing?
On 8 November 2013 16:49, Tobias Pape Das.Linux@gmx.de wrote:
Hi Igor, hi list,
sorry for replying late,…
My reply was intended to stir the conversation a litte, to keep it going, which, I assume, it did. I really like your opinion, Igor :)
On 07.11.2013, at 14:28, Igor Stasenko siguctua@gmail.com wrote:
On 7 November 2013 08:58, Tobias Pape Das.Linux@gmx.de wrote: Hey Tim and all, On 07.11.2013, at 05:00, Ron Teitelbaum ron@usmedrec.com wrote:
Hey Tim,
Göran and Eliot have been discussing this. I just talked to Eliot
about it
yesterday. He said he was happy to support cmake but didn't want to
have to
do the work himself. I'm hoping that the work Göran is doing on this
now
can be turned over to Eliot when it is finished. I think there is
agreement
that combining the excellent work of pharo build with Eliot's new vm
work is
a very good thing to do. The work to merge the build environments is already being done at 3D ICC. We are working on this for the Mac
also but
have not discussed it with Ian yet.
Ron Teitelbaum
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:
squeak-dev-
bounces@lists.squeakfoundation.org] On Behalf Of tim Rowledge Sent: Wednesday, November 06, 2013 9:04 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm
build
process
Wow, no interest? Is it because make is painful or because nobody
needs to
make any more money?
I actually have interest but I am currently reluctant, for time-capturing reasons in my personal and work life.
However, Here is what I would do:
• Start from Ians CMake work, and try to generalize it for the non-Linux platforms • Windows would be kind-of straight-forward, • For OS X, I would really want to have the Cocoa-based VM stuff (aka Squeak VM 5.4.7.x) integrated and proper Xcode files generated, especially to be able to have iOS VMs built automatically. Here, some information from John McIntosh would be helpfull,
especially
a simple walk-through. I have some experience with that[1]
Despite all admiration I have for the way the PharoVM is built, there
is one
thing that bothers me: • You first somehow generate the VM sources (which is fine, and the
automated way is amazing)
• THEN, the a Script generates CMake-Files • CMake then generates Makefiles • and then finally a vm is compiled. This is one generating step too much, for my taste. Personally, I'd prefer CMake to just pick up the C-files generated by
VMMaker,
so that adding a new platform does not need to change the VMMaker…
The main big issue with 'platform-neutral' static source files, that
they tend to
grow with tons of #ifdef-s over time, reducing readability and creating
a mess.
My point is that one or another way you have to deal with platform
differences,
and the way how i prefer to do it is using smalltalk code, but not .m4 files, or .cmake files, or writing a medium novel long
configuration files
using strange (better to say weird) scripting DSL. I can express all build process logic in smalltalk, which does not
lessens the amount
of work to deal with all platform nuances and dependencies etc, but at
least it allows me to organize and shape it
into some manageable form, which is easy to change & learn.
And another difference is, that i prefer working with browser & classes
than
with dozens of directories and files lying here and there.
I did not want to imply we have to do it my way, not at all. And you are certainly right. Smalltalk is a good way to do things.
The only thing that got me thinking is, a lot of people use tools like CMake to drive build processes, and they know the edges of the domain very well. Building software can be quite complex: think Platforms, compiler quirks, SDK restrictions, cross compilations, to just name a few. CMake (even more than autotools) is quite good at these tasks, especially regarding the cross-platform part. If we now start to, effectively, reimplement CMake or autotools, we will run in the issues, those tools all have solved years ago. CMake even has beautiful output.
I think it would take an tremendous effort to get a Build tool that (only thinking of the Squeak/Pharo VM) • can build well with different compilers (Clang/Gcc, probably Microsoft) • can handle the platform-discovery (Linux, OSX, Windows, RISC!) • can handle library discovery (finding stuff like libuuid) • can do cross-compilation and the signing-stuff (iOS, perhaps android)
If we get this working, this would be amazing. I am a bit reluctant, it would be a lot of work for me…
hehe, do you think i felt something else when started work on trying make VM to be able to build automatically? i doubt anyone can find it fun to grok through dozens of dusty old source & configuration files in attempt to put some order there. i did what i did, and now we using it to build pharo. And you free to use hours we spent on what we did. as well as free to not, of course. i don't wanna advertise or convince anyone because you can just download it and see by yourself.
But sure thing, it is a question of taste. If you prefer to maintain
this:
[22 lines old CMAKE]
And/or this:
[96 lines autoconf/make/whatever]
instead of plain smalltalk code, it is up to you.
But that's about 'too much' for my taste.
I concur.
My impression is, we can choose from four “evils”[1]: 1. Accept the status quo. Painful for starters with its 8+ ways of doing essentially the same and every single one has some kind of big drawback. 2. Use CMake completely. Painful, because we have to maintain two bodies of knowledge, VMMaker and CMake. 3. Use cmake through CMakeVMMaker. Painful, because it can not fully benefit from Smalltalk nor from CMake. You have always to make up your mind whether to implement something on the Smalltalk or the CMake level 4. Have a Smalltalk-only build too. Painful, because it is going to take a lot of time.
I can accept any of them, but the first :) 2. and 3. have the benefits that they are already there, to certain degrees. (2. only in the Unix-vm part, done by Ian, 3. currently only used by the Pharo community)
How shall we as the VM community[2] decide?
Best -Tobias
[1] not really evil, only each painful to a certain degree [2] Who are we actually? • The Pharo and Squeak people, • The Cuis people • The Newspeak People • The CogVM people • Whom am I missing?
squeak-dev@lists.squeakfoundation.org
-
Bob Arning -
Chris Muller -
Chris Muller -
Craig Latta -
David T. Lewis -
Eliot Miranda -
Frank Shearar -
gettimothy -
Igor Stasenko -
Ron Teitelbaum -
tim Rowledge -
Tobias Pape -
Tom Rushworth