Enrico Migliore wrote: > Yet, I remember, that in JCHEVM I had to remove the POPT_AUTOHELP string > in a struct in order not to receive that signal, > therefore, I'm pretty much sure that somewhere in the Pthread library > there's an access to an area used to initialize constants: > something that maybe GCC likes but Windows doesn't. > That's just a guess.
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. > The documentation included in SableVM trunk is more than good. > Therefore, I would like to try do this job. I'm not sure I'll succeed > but I want to > > As far as the port is concerned, there are 3 things to talk about: > > 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. There's no need for the sablevm launcher; we already know that the harmony one works, and it is much more complete... > 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). We have a strict policy on using the "svn merge" operation. We can discuss it the day you need it. > 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 [EMAIL PROTECTED] 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 -- Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
