[Vm-dev] Squeak VM port to Google Native Client

Javier Pimás elpochodelagente at gmail.com
Wed Aug 31 13:41:49 UTC 2011


hi! We've already made it compile with PP 0.5, but it's not displaying
anything in the browser. Maybe it's the image or the browser version, or
something related to PPAPI changes. Which image and chrome version did you
use? Actually, we tried your live demo but it isn't working in our browser
either.

Regards,
 Javier

On Mon, Aug 29, 2011 at 2:15 PM, Yoshiki Ohshima <yoshiki at vpri.org> wrote:

>
> At Mon, 29 Aug 2011 11:22:03 -0300,
> Javier Pimás wrote:
> >
> > Hi Yoshiki, we are starting to work on this, and maybe you can help us. I
> wanted to know what setup did you use for the tools, and what workflow you
> follow. Some
> > questions I can think of now:
> >
> > - do you download your git repo over the squeak-svn?
> > - do you generate the code for unix and then modify by hand or you
> generate for a new platform?
> > - Is there any image code?
>
>   Hi Javier!
>
>  Last time I touched it was early May, and so much has changed in the
> Native Client SDK since then.  It was SDK 0.2 and now it is 0.5.  Good
> news is that they claim that API is now stabilizing (which should be
> somewhat different from 0.2), so now we can have a bit more stable
> version of VM, presumably.
>
>  - My git repo was basically "on its own"; Into an empty git
>    repository, I copied files (one file by one file) from squeak-svn
>    and edit them as needed.  (So, that was the discussion you quoted;
>    I still think many files can be reused with a bit more ifdefs in
>    the Unix code.)
>
>  - The annoying kind of generated files, such as config.h, were
>    indeed hand edited.
>
>  - There is no code for image side yet.  A bridge to Pepper API is
>    called for, however.
>
> > also, I'm seeing that you use a common.mk file for extra configuration
> for the makefile. Could you please pass it to me so that I get an example of
> what's missing?
>
>   Around this part of the SDK is radically changed since then.
> Common.mk in the examples/ directory looked like the following back
> then.  But it needs to be adopted the new regime.
>
> -- Yoshiki
>
> -----------------------------------
> # Copyright (c) 2011, The Native Client Authors. All rights reserved.
> # Use of this source code is governed by a BSD-style license that can be
> # found in the LICENSE file.
> #
> # Common makefile for the examples.  This has some basic variables, such as
> # CC (the compiler) and some suffix rules such as .c.o.
> #
> # The main purpose of this makefile component is to demonstrate building a
> # Native Client module (.nexe)
>
> .SUFFIXES: .c .cc .cpp .o
>
> .PHONY: check_variables
>
> ifeq ($(origin OS), undefined)
>  ifeq ($(shell uname -s), Darwin)
>    OS=Darwin
>  else
>    OS=$(shell uname -o)
>  endif
> endif
>
> ifeq ($(OS), $(filter $(OS), Windows_NT Cygwin))
>  PLATFORM = win
>  TARGET = x86
> endif
> ifeq ($(OS), $(filter $(OS), Darwin MACOS))
>  PLATFORM = mac
>  TARGET = x86
> endif
>
> # Look for 'Linux' in the $(OS) string.  $(OS) is assumed to be a Linux
> # variant if the result of $(findstring) is not empty.
> ifneq (, $(findstring Linux, $(OS)))
>  PLATFORM = linux
>  TARGET = x86
> endif
>
> PYTHON ?= /usr/bin/python
> NACL_SDK_ROOT ?= .
>
> NACL_TOOLCHAIN_DIR = toolchain/$(PLATFORM)_$(TARGET)
>
> CC = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-gcc
> CPP = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-g++
> NACL_STRIP = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-strip
> NACL_SEL_LDR32 = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl-sel_ldr
> NACL_SEL_LDR64 = $(NACL_SDK_ROOT)/$(NACL_TOOLCHAIN_DIR)/bin/nacl64-sel_ldr
>
> CFLAGS = -Wall -Wno-long-long -pthread -Werror
> OPT_FLAGS = -O2
> DEBUG_FLAGS = -g
>
> # Make all the object files depend on the entire list of header files.
>  This
> # is a little brutal, but it gets the job dome simply without a make depend
> # step.
> %_x86_32_dbg.o: %.c $(HFILES)
>        $(CC) $(CFLAGS) -m32 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $<
>
> %_x86_32_dbg.o: %.cc $(HFILES)
>        $(CPP) $(CFLAGS) -m32 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $<
>
> %_x86_64_dbg.o: %.c $(HFILES)
>        $(CC) $(CFLAGS) -m64 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $<
>
> %_x86_64_dbg.o: %.cc $(HFILES)
>        $(CPP) $(CFLAGS) -m64 $(INCLUDES) $(DEBUG_FLAGS) -c -o $@ $<
>
> %_x86_32.o: %.c $(HFILES)
>        $(CC) $(CFLAGS) -m32 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $<
>
> %_x86_32.o: %.cc $(HFILES)
>        $(CPP) $(CFLAGS) -m32 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $<
>
> %_x86_32.o: %.cpp $(HFILES)
>        $(CPP) $(CFLAGS) -m32 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $<
>
> %_x86_64.o: %.c $(HFILES)
>        $(CC) $(CFLAGS) -m64 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $<
>
> %_x86_64.o: %.cc $(HFILES)
>        $(CPP) $(CFLAGS) -m64 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $<
>
> %_x86_64.o: %.cpp $(HFILES)
>        $(CPP) $(CFLAGS) -m64 $(INCLUDES) $(OPT_FLAGS) -c -o $@ $<
>
> # Generate list of .o files based on the list of .c and .cc files
> OBJECTS_X86_32 = $(CFILES:%.c=%_x86_32.o) $(CCFILES:%.cc=%_x86_32.o)
> OBJECTS_X86_64 = $(CFILES:%.c=%_x86_64.o) $(CCFILES:%.cc=%_x86_64.o)
> OBJECTS_X86_32_DBG = $(CFILES:%.c=%_x86_32_dbg.o)
> $(CCFILES:%.cc=%_x86_32_dbg.o)
> OBJECTS_X86_64_DBG = $(CFILES:%.c=%_x86_64_dbg.o)
> $(CCFILES:%.cc=%_x86_64_dbg.o)
>
> # Make sure certain variables are defined.  This rule is set as a
> dependency
> # for all the .nexe builds in the examples.
> check_variables:
> ifeq ($(origin OS), undefined)
>        @echo "Error: OS is undefined" ; exit 42
> endif
> ifeq ($(origin PLATFORM), undefined)
>        @echo "Error: PLATFORM is undefined (OS = $(OS))" ; exit 42
> endif
> ifeq ($(origin TARGET), undefined)
>        @echo "Error: TARGET is undefined (OS = $(OS))" ; exit 42
> endif
> ifeq ($(origin NACL_SDK_ROOT), undefined)
>        @echo "Error: NACL_SDK_ROOT is undefined" ; exit 42
> endif
>



-- 
Lic. Javier Pimás
Ciudad de Buenos Aires
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110831/8cc9a559/attachment.htm


More information about the Vm-dev mailing list