[sablevm-jchevm] Windows port

Hi Etienne,

>I have to look more carfully to the port library, and see what thread
>supports it provides.  I've had lots of professorish things to do over
>the last days, so I didn't get enough time to look deeply.  I'll get
>back to you about it.
>
>  
>
Ok.
In any case, I think that the Windows port should rely on the pthread 
library written for Windows.
To speed the execution time, in the future, we might want to inline the 
pthread functions used.

>>build system in MSVC
>>-----------------------
>>to my knowledge, MSVC doesn't have a build system like UNIX (autotool +
>>configure) therefore, I think that the "config.h" file will have to be
>>built manually.
>>    
>>
>
>This shouldn't be too much of a problem.  SableVM has no intrinsict
>dependence on auto* tools.  It does, however, require m4.  This could be
>eliminated if we decided to allow for a Java dependency for building
>(i.e. ant & sablecc-based code generator).
>
>Yet, on shorter term, some simpler make file is feasible.  All you
>actually need to build is libsablevm.dll.
>
A makefile and a workspace file.

>  There's no need for the
>sablevm launcher; we already know that the harmony one works, and it is
>much more complete...
>
>  
>
Ok

>>how to modify the source files?
>>------------------------------
>>Let's say that removing a POSIX dependancy in a SableVM file means:
>>replacing some lines of codes and replacing some include files. How am I
>>suppost to deal with this kind of thing? Should I modify the trunk or my
>>sandbox?
>>    
>>
>
>Ideally, initial work should happen in your sandbox.  This way you can
>use it to do backups of your code, even when it doesn't compile, without
>disturbing anybody.
>
>I am playing with the idea of making a copy of current trunk in
>sablevm/branches/last-stable, and simply allowing for a broken trunk
>during the Harmony transition (not as broken as a typical sandbox;
>should at least compile).
>
>  
>
Ok, got it.

>We have a strict policy on using the "svn merge" operation.  We can
>discuss it the day you need it.
>
>  
>
Ok

>>how to track source modifications
>>----------------------------------
>>Let's say that one source file gets modified by one of SableVM
>>developers, and another is added to the trunk. Should I rely on SVN to
>>know where the modifications were done?
>>    
>>
>
>Not sure I understand the question...  Developers may only checkin code
>they wrote themselves.  This way, svn keeps a clear history of who wrote
>what.
>
>I think this discussion should probably continue on sablevm-devel@, as
>not to add too much noise into harmony-dev@.  We could, there, discuss
>of work distribution among you, hadrien and me, as well as any other
>interested contributor, to get a working sablevm+harmony duo as soon and
>as cleanly as possible.
>
>We should come back to this list for any topic related to the class-lib
>and port library side of things.
>
>Etienne
>
>  
>
Ok, all is clear now.


The port is not trivial, not easy, not a quick-and-dirty work, therefore 
in order to do it right, I'm gonna make a written roadmap, based on:

 1. SableVM source code inspection

 2. libffi source code inspection

 3. popt source code inspection


Before starting to modify the source files, I'll generate a working 
version of SableVM:

./configure --option-1 --option-2 ... --option-n

and work up until the end of the port.


I also would like to make a written report of the work in order to allow 
the port of JCHEVM without re-discovering the wheel.


Enrico