<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Georgia">It's absolutely none of my business what tools
others choose to use, but I will say this:<br>
<br>
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.<br>
<br>
Cheers,<br>
Bob<br>
<br>
</font>
<div class="moz-cite-prefix">On 11/7/13 8:28 AM, Igor Stasenko
wrote:<br>
</div>
<blockquote
cite="mid:CAEYrNzDT6LffKn3NLzBHEc7Xf8-DaANjijv1beYiqxBApPntNg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 7 November 2013 08:58, Tobias Pape
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Hey Tim and all,<br>
<div>
<div class="h5">On 07.11.2013, at 05:00, Ron Teitelbaum
<<a moz-do-not-send="true"
href="mailto:ron@usmedrec.com">ron@usmedrec.com</a>>
wrote:<br>
<br>
> Hey Tim,<br>
><br>
> Göran and Eliot have been discussing this. I
just talked to Eliot about it<br>
> yesterday. He said he was happy to support cmake
but didn't want to have to<br>
> do the work himself. I'm hoping that the work
Göran is doing on this now<br>
> can be turned over to Eliot when it is finished.
I think there is agreement<br>
> that combining the excellent work of pharo build
with Eliot's new vm work is<br>
> a very good thing to do. The work to merge the
build environments is<br>
> already being done at 3D ICC. We are working on
this for the Mac also but<br>
> have not discussed it with Ian yet.<br>
><br>
> Ron Teitelbaum<br>
><br>
>> -----Original Message-----<br>
>> From: <a moz-do-not-send="true"
href="mailto:squeak-dev-bounces@lists.squeakfoundation.org">squeak-dev-bounces@lists.squeakfoundation.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:squeak-dev-">squeak-dev-</a><br>
>> <a moz-do-not-send="true"
href="mailto:bounces@lists.squeakfoundation.org">bounces@lists.squeakfoundation.org</a>]
On Behalf Of tim Rowledge<br>
>> Sent: Wednesday, November 06, 2013 9:04 PM<br>
>> To: The general-purpose Squeak developers
list<br>
>> Subject: Re: [squeak-dev] A Bounty for
CMake-ifying stack/Cog vm build<br>
> process<br>
>><br>
>><br>
>> Wow, no interest? Is it because make is
painful or because nobody needs to<br>
>> make any more money?<br>
<br>
<br>
</div>
</div>
I actually have interest but I am currently reluctant,<br>
for time-capturing reasons in my personal and work life.<br>
<br>
However, Here is what I would do:<br>
<br>
• Start from Ians CMake work, and try to generalize it for
the<br>
non-Linux platforms<br>
• Windows would be kind-of straight-forward,<br>
• For OS X, I would really want to have the Cocoa-based VM
stuff<br>
(aka Squeak VM 5.4.7.x) integrated and proper Xcode
files<br>
generated, especially to be able to have iOS VMs built
automatically.<br>
Here, some information from John McIntosh would be
helpfull, especially<br>
a simple walk-through.<br>
I have some experience with that[1]<br>
<br>
<br>
Despite all admiration I have for the way the PharoVM is
built, there is one<br>
thing that bothers me:<br>
• You first somehow generate the VM sources (which is
fine, and the automated way is amazing)<br>
• THEN, the a Script generates CMake-Files<br>
• CMake then generates Makefiles<br>
• and then finally a vm is compiled.<br>
This is one generating step too much, for my taste.<br>
Personally, I'd prefer CMake to just pick up the C-files
generated by VMMaker,<br>
so that adding a new platform does not need to change the
VMMaker…</blockquote>
<div><br>
</div>
<div>The main big issue with 'platform-neutral' static
source files, that they tend to<br>
</div>
<div>grow with tons of #ifdef-s over time, reducing
readability and creating a mess.<br>
<br>
</div>
<div>My point is that one or another way you have to deal
with platform differences,<br>
</div>
<div>and the way how i prefer to do it is using smalltalk
code,<br>
</div>
<div>but not .m4 files, or .cmake files, or writing a medium
novel long configuration files<br>
</div>
<div>using strange (better to say weird) scripting DSL.<br>
</div>
<div>I can express all build process logic in smalltalk,
which does not lessens the amount<br>
of work to deal with all platform nuances and dependencies
etc, but at least it allows me to organize and shape it<br>
into some manageable form, which is easy to change &
learn.<br>
</div>
<div> <br>
</div>
<div> And another difference is, that i prefer working with
browser & classes than<br>
with dozens of directories and files lying here and there.<br>
<br>
</div>
<div>But sure thing, it is a question of taste. If you
prefer to maintain this:<br>
-------------------------<br>
MACRO (INTERNAL_PLUGIN plugin)<br>
SET (plugin_sources "")<br>
IF (DEFINED ${plugin}_sources)<br>
SET (plugin_sources ${${plugin}_sources})<br>
ELSE (DEFINED ${plugin}_sources)<br>
FOREACH (dir ${src}/vm/intplugins ${cross}/plugins
${unix}/plugins)<br>
SET (tmp "")<br>
AUX_SOURCE_DIRECTORY (${dir}/${plugin} tmp)<br>
STRING_APPEND (plugin_sources "${tmp}")<br>
ENDFOREACH (dir)<br>
ENDIF (DEFINED ${plugin}_sources)<br>
IF (DEFINED ${plugin}_extra_sources)<br>
STRING_APPEND (plugin_sources
"${${plugin}_extra_sources}")<br>
ENDIF (DEFINED ${plugin}_extra_sources)<br>
FILE (WRITE ${bld}/${plugin}/CMakeLists.in "")<br>
FOREACH (dir ${unix}/plugins ${unix})<br>
FILE_APPEND (${bld}/${plugin}/CMakeLists.in
${dir}/${plugin}/build.cmake)<br>
ENDFOREACH (dir)<br>
FILE_APPEND (${bld}/${plugin}/CMakeLists.in
${config}/PluginInternal.cmake)<br>
CONFIGURE_FILE (${bld}/${plugin}/CMakeLists.in
${bld}/${plugin}/CMakeLists.txt @ONLY)<br>
ADD_SUBDIRECTORY (${bld}/${plugin} ${bld}/${plugin})<br>
ENDMACRO (INTERNAL_PLUGIN)<br>
--------------------------<br>
</div>
<div>And/or this:<br>
--------------------------<br>
AC_INIT([<a moz-do-not-send="true"
href="http://config.h.in">config.h.in</a>])<br>
<br>
SVNREV=`grep '\$Rev: '
${srcdir}/../../../platforms/Cross/vm/sqSCCSVersion.h \<br>
| sed 's/.*$Rev: \([[0-9]][[0-9]]*\).*/\1/'`<br>
AC_VM_VERSION(4,0,${SVNREV},4,2,0)<br>
<br>
topdir=`cd ${srcdir}/../../..; pwd`<br>
cfgdir=`cd ${srcdir}; pwd`<br>
<br>
AC_ARG_WITH(src,<br>
[ --with-src=dir generated src directory
[default=src]],<br>
[ vmmsrc="${with_src}"],<br>
[ vmmsrc="src"])<br>
<br>
vmmdir="${topdir}/${vmmsrc}"<br>
<br>
if test ! -d "${topdir}/${vmmsrc}"; then<br>
if test -d "${topdir}/platforms/unix/${vmmsrc}"; then<br>
vmmdir="${topdir}/platforms/unix/${vmmsrc}"<br>
AC_MSG_RESULT([using built-in src directory])<br>
fi<br>
fi<br>
<br>
AC_MSG_RESULT(${vmmdir})<br>
<br>
blddir=`pwd`<br>
<br>
AC_ARG_WITH(vmmcfg,<br>
[ --with-vmmcfg=dir vm configuration directory
containing <a moz-do-not-send="true"
href="http://plugins.int">plugins.int</a> and
plugins.ext [default=.]],<br>
[ vmmcfg="${with-vmmcfg}"],<br>
[ vmmcfg="${blddir}"])<br>
<br>
# Compiling a Cogit VM or not? If so, need a cogit$o,
cointerp, etc.<br>
<br>
AC_ARG_ENABLE(cogit,<br>
[ --enable-cogit compile a cogit VM
[default=yes]],<br>
cogit="no", cogit="yes")<br>
AC_SUBST(cogit)<br>
<br>
#AC_ARG_ENABLE(jit,<br>
#[ --enable-jit enable J4 support
[default=no]],<br>
#JIT="yes", JIT="no")<br>
#<br>
#test $JIT = "yes" && J_CFLAGS="-DJ_ENABLED"<br>
#AC_SUBST(J_CFLAGS)<br>
<br>
# Check the generated src dir looks sane<br>
<br>
AC_CHECK_VMM_DIR<br>
<br>
AC_SUBST(topdir)<br>
AC_SUBST(cfgdir)<br>
AC_SUBST(vmmdir)<br>
AC_SUBST(vmmcfg)<br>
AC_SUBST(blddir)<br>
<br>
SQ_VERSION=${SQ_MAJOR}.${SQ_MINOR}-${SQ_UPDATE}<br>
<br>
AC_DEFINE_UNQUOTED(SQ_VERSION, "${SQ_VERSION}")<br>
<br>
AC_SUBST(SQ_MAJOR)<br>
AC_SUBST(SQ_MINOR)<br>
AC_SUBST(SQ_UPDATE)<br>
AC_SUBST(SQ_VERSION)<br>
<br>
VM_VERSION=${VM_MAJOR}.${VM_MINOR}-${VM_RELEASE}<br>
<br>
AC_DEFINE_UNQUOTED(VM_VERSION, "${VM_VERSION}")<br>
<br>
AC_SUBST(VM_MAJOR)<br>
AC_SUBST(VM_MINOR)<br>
AC_SUBST(VM_RELEASE)<br>
AC_SUBST(VM_VERSION)<br>
<br>
# libdir contains ${exec_prefix}, so we have to default
and expand early<br>
test "x$prefix" = xNONE &&
prefix=$ac_default_prefix<br>
test "x$exec_prefix" = xNONE &&
exec_prefix='${prefix}'<br>
imgdir=`eval echo ${libdir}/squeak`<br>
expanded_relative_imgdir=`eval echo
lib/squeak/${VM_VERSION}`<br>
plgdir='${imgdir}/'`eval echo ${VM_VERSION}`<br>
<br>
AC_SUBST(imgdir)<br>
AC_SUBST(expanded_relative_imgdir)<br>
AC_SUBST(plgdir)<br>
<br>
AC_DEFINE(OS_TYPE, "unix")<br>
<br>
AC_CANONICAL_HOST<br>
<br>
host_cpu=`echo $host | sed 's,-.*,,'`<br>
host=`echo $host | sed 's,-unknown,,'`<br>
<br>
AC_SUBST(host)<br>
AC_SUBST(host_cpu)<br>
AC_SUBST(host_vendor)<br>
AC_SUBST(host_os)<br>
----------------------------<br>
<br>
</div>
<div>instead of plain smalltalk code, it is up to you.<br>
<br>
</div>
<div>But that's about 'too much' for my taste. <br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
But if the community is positive to just move to the Pharo
way of<br>
building VMs, I'd be fine with that, since that would
unify a lot<br>
of infrastructure :)<br>
<br>
Best<br>
-Tobias<br>
<br>
[1] <a moz-do-not-send="true"
href="https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake"
target="_blank">https://github.com/krono/self/blob/cmake/vm/cmake/mac_osx.cmake</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Best regards,<br>
Igor Stasenko.
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>