Geir Magnusson Jr wrote:
Tim Ellison wrote:
Enrico Migliore wrote:
Hi Tim,
Enrico Migliore wrote:
Archie, Geir and Stefano,
could you please take a look at the following assertion and
correct it
if it's wrong:
It's worth to remember, that the goal of porting JCHEVM to
Cygwin/Windows,
is to enable us, and the people interested, to have a development
environment on Windows,
in order to start working on the APR.
I'm not sure what you mean by 'in order to start working on the APR'?
I meant, modifying JCHEVM in order to call, where applicable, the APR
functions.
In principle, after adapting jchevm to the APR, jchevm will be
buildable
with:
1. GCC native - build on Linux an executable for Linux
2. GCC cross native - build on Linux an executable for Windows
(without Cygwin)
3. MSVC native - build on Windows an executable for Windows
The same thing applies to the Harmony Classlib
The class library native code uses the Harmony portlib to access
much of
the OS-specific code covered in APR. Rather than rewrite those
natives,
and loose the additional characteristics of the portlib, it would make
more sense to implement the portlib on APR if that were desirable.
I think I'm missing something: last week, we all agreed on "adopting"
the APR library for the native
stuff, except for the windowing subsystem. That means to me that all
the
functions of JCHEVM and the Harmony,
that need to access an OS/platform service (filesystem, network, etc.)
should call the APR library.
No we didn't agree to do that Enrico, for the reasons I described above.
Just to reinforce... no, we didn't agree to that.
I think that the notion leveraging APR for implementing the
portability layer for the VM was what we didn't disagree on. ( I
won't claim agreement...)
But that's way different than APR for the class lib portlib.
So you have to create a apr.IA32 class lib, don't you?
Cheers
Jean-Frederic
geir
Regards,
Tim
