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