harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-frederic Clere <jfcl...@gmail.com>
Subject Re: [jchevm] APR issues
Date Mon, 27 Feb 2006 08:42:43 GMT
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
>>
>


Mime
View raw message