A Bounty for CMake-ifying stack/Cog vm build process

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

A Bounty for CMake-ifying stack/Cog vm build process

timrowledge
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; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Canis meus id comedit = My dog ate it.



Reply | Threaded
Open this post in threaded view
|

Re: A Bounty for CMake-ifying stack/Cog vm build process

Igor Stasenko


On 31 October 2013 21:16, tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Canis meus id comedit = My dog ate it.






--
Best regards,
Igor Stasenko.


Reply | Threaded
Open this post in threaded view
|

Re: A Bounty for CMake-ifying stack/Cog vm build process

Igor Stasenko


On 31 October 2013 21:21, Igor Stasenko <[hidden email]> wrote:

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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Canis meus id comedit = My dog ate it.






--
Best regards,
Igor Stasenko.



--
Best regards,
Igor Stasenko.


Reply | Threaded
Open this post in threaded view
|

Re: A Bounty for CMake-ifying stack/Cog vm build process

timrowledge
In reply to this post by Igor Stasenko

On 31-10-2013, at 1:21 PM, Igor Stasenko <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
May the bugs of many programs nest on your hard drive.



Reply | Threaded
Open this post in threaded view
|

Re: A Bounty for CMake-ifying stack/Cog vm build process

timrowledge
In reply to this post by Igor Stasenko

On 31-10-2013, at 1:30 PM, Igor Stasenko <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
"Virtual Memory" means never knowing where your next byte is coming from.





Reply | Threaded
Open this post in threaded view
|

Re: A Bounty for CMake-ifying stack/Cog vm build process

Igor Stasenko
In reply to this post by timrowledge



On 31 October 2013 21:38, tim Rowledge <[hidden email]> wrote:

On 31-10-2013, at 1:21 PM, Igor Stasenko <[hidden email]> 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).


May the bugs of many programs nest on your hard drive.






--
Best regards,
Igor Stasenko.


Reply | Threaded
Open this post in threaded view
|

Re: A Bounty for CMake-ifying stack/Cog vm build process

Igor Stasenko
In reply to this post by timrowledge



On 31 October 2013 21:40, tim Rowledge <[hidden email]> wrote:

On 31-10-2013, at 1:30 PM, Igor Stasenko <[hidden email]> 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.package/StackEvtAndroidConfig.class
 
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.

"Virtual Memory" means never knowing where your next byte is coming from.








--
Best regards,
Igor Stasenko.


Reply | Threaded
Open this post in threaded view
|

Re: A Bounty for CMake-ifying stack/Cog vm build process

timrowledge
In reply to this post by timrowledge

Wow, no interest? Is it because make is painful or because nobody needs to make any more money?

tim
>

Reply | Threaded
Open this post in threaded view
|

RE: A Bounty for CMake-ifying stack/Cog vm build process

Ron Teitelbaum
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: [hidden email] [mailto:squeak-dev-
> [hidden email]] 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
> >
>



Reply | Threaded
Open this post in threaded view
|

Re: A Bounty for CMake-ifying stack/Cog vm build process

Tobias Pape
Hey Tim and all,
On 07.11.2013, at 05:00, Ron Teitelbaum <[hidden email]> 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: [hidden email] [mailto:squeak-dev-
>> [hidden email]] 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







signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A Bounty for CMake-ifying stack/Cog vm build process

Igor Stasenko



On 7 November 2013 08:58, Tobias Pape <[hidden email]> wrote:
Hey Tim and all,
On 07.11.2013, at 05:00, Ron Teitelbaum <[hidden email]> 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: [hidden email] [mailto:[hidden email]
>> [hidden email]] 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.


Reply | Threaded
Open this post in threaded view
|

Re: A Bounty for CMake-ifying stack/Cog vm build process

Bob Arning-2
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 <[hidden email]> wrote:
Hey Tim and all,
On 07.11.2013, at 05:00, Ron Teitelbaum <[hidden email]> 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: [hidden email] [mailto:[hidden email]
>> [hidden email]] 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.



    



Reply | Threaded
Open this post in threaded view
|

Re: A Bounty for CMake-ifying stack/Cog vm build process

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 <[hidden email]> 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 <[hidden email]> wrote:
Hey Tim and all,
On 07.11.2013, at 05:00, Ron Teitelbaum <[hidden email]> 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: [hidden email] [mailto:[hidden email]
>> [hidden email]] 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 regards,
Igor Stasenko.


tty
Reply | Threaded
Open this post in threaded view
|

Re: A Bounty for CMake-ifying stack/Cog vm build process

tty
In reply to this post by Bob Arning-2
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<[hidden email]> 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:
[hidden email]" type="cite">



On 7 November 2013 08:58, Tobias Pape <[hidden email]> wrote:
Hey Tim and all,
On 07.11.2013, at 05:00, Ron Teitelbaum <[hidden email]> 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: [hidden email] [mailto:[hidden email]
>> [hidden email]] 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.


 





Reply | Threaded
Open this post in threaded view
|

re: A Bounty for CMake-ifying stack/Cog vm build process

ccrraaiigg
In reply to this post by Igor Stasenko

     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)


Reply | Threaded
Open this post in threaded view
|

re: A Bounty for CMake-ifying stack/Cog vm build process

Ron Teitelbaum
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: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Craig Latta
> Sent: Thursday, November 07, 2013 10:22 AM
> To: [hidden email]
> 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)
>
>



Reply | Threaded
Open this post in threaded view
|

Re: A Bounty for CMake-ifying stack/Cog vm build process

Eliot Miranda-2
In reply to this post by tty
Hi Timothy,


On Thu, Nov 7, 2013 at 7:02 AM, gettimothy <[hidden email]> 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<[hidden email]> 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:
[hidden email]" type="cite">



On 7 November 2013 08:58, Tobias Pape <[hidden email]> wrote:
Hey Tim and all,
On 07.11.2013, at 05:00, Ron Teitelbaum <[hidden email]> 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: [hidden email] [mailto:[hidden email]
>> [hidden email]] 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


Reply | Threaded
Open this post in threaded view
|

re: A Bounty for CMake-ifying stack/Cog vm build process

timrowledge
In reply to this post by Ron Teitelbaum


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.

Reply | Threaded
Open this post in threaded view
|

re: A Bounty for CMake-ifying stack/Cog vm build process

Chris Muller-3
Deployment should be regarded a separate problem than building.

On Thu, Nov 7, 2013 at 2:00 PM, tim Rowledge <[hidden email]> 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.
>

tty
Reply | Threaded
Open this post in threaded view
|

Re: A Bounty for CMake-ifying stack/Cog vm build process

tty
In reply to this post by Eliot Miranda-2
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<[hidden email]> wrote ----

Hi Timothy,


On Thu, Nov 7, 2013 at 7:02 AM, gettimothy <[hidden email]> 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<[hidden email]> 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:
[hidden email]" type="cite">



On 7 November 2013 08:58, Tobias Pape <[hidden email]> wrote:
Hey Tim and all,
On 07.11.2013, at 05:00, Ron Teitelbaum <[hidden email]> 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: [hidden email] [mailto:[hidden email]
>> [hidden email]] 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




123