[Vm-dev] VM Maker: CMakeVMMakerSqueak-tty.43.mcz

[Eliot Miranda]

On Tue, Jun 10, 2014 at 5:30 PM, gettimothy <gettimothy at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140610/72774cf0/attachment-0001.htm