On Tue, Jun 10, 2014 at 5:30 PM, gettimothy <gettimothy@zoho.com> wrote:
��
Hi Eliot.



Hi All,

�� �� in the below, everything looks sane except configH. ��This looks like an awful mistake. ��It appears to be capturing the output of an autoconf or CMake run, determining things like USE_X11 USE_X11_GLX USE_QUARTZ USE_QUARTZ_CGL USE_RFB HAVE_LIBX11 ��HAVE_LIBXEXT HAVE_LIBDL HAVE_DYLD HAVE_LIBFFI etc that should be determined at VM configure time, on the host system, immediately before compile, /not/ at source generation time. ��What's going on here?



I don't know yet. That is pharo code.Let me explain my modus-operandi.

Yes, and my question was aimed at the Pharo VM folks. ��This part of the build process, choosing the right configuration for the host OS, is key, so it's alarming to see it presented wrongly here. ��I'm confident you'll take the right approach. ��But I was anxious to raise the issue with Igor, Esteban and anyone else who can shine a light on this. ��Hopefully we can fix it easily.
��

First pass in the CMakeVMMakerSqueak was scripts that set up the build environment.

Second pass was getting the Pharo code/builds/configurations�� to work on Squeak. That is done, and I have thrown that work away.(actually, it is banished to the island of misfit toys category...)


Third pass is Squeak-ifying the tool to match the squeak build configs of [OS][WordSize][Processor]/[Language][VM][MemoryManager]/[assert|assert.itimerheartbeat| debug....etc] (i.e. build.linux32x86/squeak.cog.spur/assert)
(I also spent significant time on expanding the Builder's functionality with an eye towards automating builds and easing use.)

Third pass involves some very significant refactoring with each [OS][WordSize][Processor] category having a base��configuration with dedicated [Language][VM][MemoryManager] configurations under that which can configure themselves for��[assert|assert.itimerheartbeat| debug....etc]

My first goal in Pass 3 is to recreate Pass 2 for the builds that worked. <----I AM HERE

After that, I am going to look at your mvm's on the GNU side and attempt to precisely match what you have. At that point, I will address what the pharo code is actually doing at the configuration step.

Then, I will be in rote-coding mode to implement that.

However, looking at your email, I see what you mean. Those should be set up earlier as in the first line below.



test -f config.h || ../../../platforms/unix/config/configure --without-npsqueak \
CC="gcc -m32" \
CXX="g++ -m32" \
CFLAGS="$OPT -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DCOGMTVM=0" \
LIBS="-lpthread -luuid" \
LDFLAGS=-Wl,-z,now
../../../scripts/nukeversion
rm -rf ../../../products/$INSTALLDIR
# prefer make install prefix=`readlink -f \`pwd\`/../../../products/$INSTALLDIR`
# but older linux readlinks lack the -f flag
make install prefix=`(cd ../../../;pwd)`/products/$INSTALLDIR 2>&1 | tee LOG

I will be back on this in the morning. Remember, I just want to recreate Pass 2 so that I am getting CMakeLists.txt files and source code when created. Then, I will fine tune each Language][VM][MemoryManager]/[assert|assert.itimerheartbeat| debug....etc] in the Linux32 tree.
At that point, we should all have a good feel for this beast and it should be a decent tool.

cheers.

tty��








--
best,
Eliot