You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Enrico Migliore <en...@fatti.com> on 2006/02/20 17:14:43 UTC
[jchevm] APR issues
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.
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
Enrico
Re: [jchevm] APR issues
Posted by Enrico Migliore <en...@fatti.com>.
>>The cygwin.dll acts as an emulation layer for all those POSIX functions
>>that
>>Windows doesn't have. If a program doesn't call any of the functions
>>provided
>>by cygwin.dll, then, this library is not needed and, I guess, it's not
>>even loaded.
>>
>>GCC, when used on Cygwin, produces always a native executable file for
>>Windows, and
>>the extension is .exe.
>>
>>
>
>Actually you have a choice now. Cygwin gcc can build for cygwin.dll
>or, with "gcc -mno-cygwin", for the native msvcrt.dll. The latter
>does not require cygwin.dll.
>
>Regards,
> Mark.
>
>
Hi Mark,
thanks for pointing that out. I'll try to build JCHEVM with that option
enabled.
I figure that if I try to build a program that makes use of POSIX
functions,
with "gcc -mno-cygwin", there are two options:
1. Those functions will be embedded in the executable file (.exe)
2. GCC refuses to build
Enrico
Re: [jchevm] APR issues
Posted by Mark Hindess <ma...@googlemail.com>.
On 27/02/06, Enrico Migliore <en...@fatti.com> wrote:
> Hi,
>
> >> So what we'd need now is a mechanism to override
> >> the automatic choice of "platform". I wouldn't be too surprised if
> >> someone decided to create "platforms" for the other two (?) choices of
> >> windows implementation - cygwin native and cygwin w/o cygwin.dll.
> >>
> >>
> > ??? native windoze and cygwin, or do I miss something?
>
> The cygwin.dll acts as an emulation layer for all those POSIX functions
> that
> Windows doesn't have. If a program doesn't call any of the functions
> provided
> by cygwin.dll, then, this library is not needed and, I guess, it's not
> even loaded.
>
> GCC, when used on Cygwin, produces always a native executable file for
> Windows, and
> the extension is .exe.
Actually you have a choice now. Cygwin gcc can build for cygwin.dll
or, with "gcc -mno-cygwin", for the native msvcrt.dll. The latter
does not require cygwin.dll.
Regards,
Mark.
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
Re: [jchevm] APR issues
Posted by Enrico Migliore <en...@fatti.com>.
Hi,
>> So what we'd need now is a mechanism to override
>> the automatic choice of "platform". I wouldn't be too surprised if
>> someone decided to create "platforms" for the other two (?) choices of
>> windows implementation - cygwin native and cygwin w/o cygwin.dll.
>>
>>
> ??? native windoze and cygwin, or do I miss something?
The cygwin.dll acts as an emulation layer for all those POSIX functions
that
Windows doesn't have. If a program doesn't call any of the functions
provided
by cygwin.dll, then, this library is not needed and, I guess, it's not
even loaded.
GCC, when used on Cygwin, produces always a native executable file for
Windows, and
the extension is .exe.
Enrico
Re: [jchevm] APR issues
Posted by Mark Hindess <ma...@googlemail.com>.
On 27/02/06, Jean-frederic Clere <jf...@gmail.com> wrote:
> Mark Hindess wrote:
>
> >On 27/02/06, Jean-frederic Clere <jf...@gmail.com> wrote:
> >
> >
> >>Geir Magnusson Jr wrote:
> >>
> >>
> >>>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?
> >>
> >>
> >
> >Well, that's what I was thinking - though I'm not so sure that $arch
> >should be something that specific.
> >
> >Initially at least I don't think we should be making a choice between
> >using apr.IA32 and writing platform specific natives. I think we
> >should continue with what we have until such a time that apr becomes
> >the better choice.
> >
> I am not sure that is the best idea.
> Apr prevents losing time writing code twice (or #defining everywhere)
> and that is a lot of work to APRized a project in late state.
> Starting with apr asap probably will break everything for some time but
> will spare a lot of time in future...
> The biggest problem is to have a graphical library that works with apr
> or that is written using apr.
I wasn't saying don't start an apr.$arch platform just don't make that
the only option. It should be developed in parallel. I don't see why
it should be any more difficult than developing the win.IA32 and
linux.IA32 in parallel has been?
> > So what we'd need now is a mechanism to override
> >the automatic choice of "platform". I wouldn't be too surprised if
> >someone decided to create "platforms" for the other two (?) choices of
> >windows implementation - cygwin native and cygwin w/o cygwin.dll.
> >
> ??? native windoze and cygwin, or do I miss something?
That should be sufficient, but I was making the additional distinction between
windows native built with nmake/MSVC (as we have today) and windows
native built with cygwin ("gmake/gcc -mno-cygwin"). These are
sufficiently different that if anyone wanted them today they'd
probably treat them as separate platforms until we get the natives in
a better state.
> >It might be useful to develop some tests to prove the natives for
> >platforms that don't yet have VM support.
Regards,
Mark.
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
Re: [jchevm] APR issues
Posted by Jean-frederic Clere <jf...@gmail.com>.
Mark Hindess wrote:
>On 27/02/06, Jean-frederic Clere <jf...@gmail.com> wrote:
>
>
>>Geir Magnusson Jr wrote:
>>
>>
>>>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?
>>
>>
>
>Well, that's what I was thinking - though I'm not so sure that $arch
>should be something that specific.
>
>Initially at least I don't think we should be making a choice between
>using apr.IA32 and writing platform specific natives. I think we
>should continue with what we have until such a time that apr becomes
>the better choice.
>
I am not sure that is the best idea.
Apr prevents losing time writing code twice (or #defining everywhere)
and that is a lot of work to APRized a project in late state.
Starting with apr asap probably will break everything for some time but
will spare a lot of time in future...
The biggest problem is to have a graphical library that works with apr
or that is written using apr.
> So what we'd need now is a mechanism to override
>the automatic choice of "platform". I wouldn't be too surprised if
>someone decided to create "platforms" for the other two (?) choices of
>windows implementation - cygwin native and cygwin w/o cygwin.dll.
>
>
??? native windoze and cygwin, or do I miss something?
>It might be useful to develop some tests to prove the natives for
>platforms that don't yet have VM support.
>
>Regards,
> Mark.
>
>--
>Mark Hindess <ma...@googlemail.com>
>IBM Java Technology Centre, UK.
>
>
>
Re: [jchevm] APR issues
Posted by Enrico Migliore <en...@fatti.com>.
Hi,
>Initially at least I don't think we should be making a choice between
>using apr.IA32 and writing platform specific natives. I think we
>should continue with what we have until such a time that apr becomes
>the better choice.
>
I agree with you.
>So what we'd need now is a mechanism to override
>the automatic choice of "platform". I wouldn't be too surprised if
>someone decided to create "platforms" for the other two (?) choices of
>windows implementation - cygwin native and cygwin w/o cygwin.dll.
>
>It might be useful to develop some tests to prove the natives for
>platforms that don't yet have VM support.
>
>Regards,
> Mark.
>
>--
>Mark Hindess <ma...@googlemail.com>
>IBM Java Technology Centre, UK.
>
>
>
Enrico
Re: [jchevm] APR issues
Posted by Mark Hindess <ma...@googlemail.com>.
On 27/02/06, Jean-frederic Clere <jf...@gmail.com> wrote:
> Geir Magnusson Jr wrote:
> >
> > 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?
Well, that's what I was thinking - though I'm not so sure that $arch
should be something that specific.
Initially at least I don't think we should be making a choice between
using apr.IA32 and writing platform specific natives. I think we
should continue with what we have until such a time that apr becomes
the better choice. So what we'd need now is a mechanism to override
the automatic choice of "platform". I wouldn't be too surprised if
someone decided to create "platforms" for the other two (?) choices of
windows implementation - cygwin native and cygwin w/o cygwin.dll.
It might be useful to develop some tests to prove the natives for
platforms that don't yet have VM support.
Regards,
Mark.
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
Re: [jchevm] APR issues
Posted by Jean-frederic Clere <jf...@gmail.com>.
Geir Magnusson Jr wrote:
>
>
> Jean-frederic Clere wrote:
>
>> Geir Magnusson Jr wrote:
>>
>>>
>>>
>>> Tim Ellison wrote:
>>
>
>>>> 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?
>
>
> I think I don't understand the question.
>
> Yes, we can do an implementation using APR, but what I thought was
> driving this discussion was the idea that we could abandon portlib and
> tie everything directly to the APR API.
Ok, I understand better the idea: no apr portlib but everything in the
jchecvm.
>
> Using APR to implement the porting layer for the VM/classlib is just
> peachy - it saves us oodles of work.
>
> geir
>
>>
>> Cheers
>>
>> Jean-Frederic
>>
>>>
>>>
>>> geir
>>>
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>
>>
>>
>
>
Re: [jchevm] APR issues
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Jean-frederic Clere wrote:
> Geir Magnusson Jr wrote:
>
>>
>>
>> Tim Ellison wrote:
>>> 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?
I think I don't understand the question.
Yes, we can do an implementation using APR, but what I thought was
driving this discussion was the idea that we could abandon portlib and
tie everything directly to the APR API.
Using APR to implement the porting layer for the VM/classlib is just
peachy - it saves us oodles of work.
geir
>
> Cheers
>
> Jean-Frederic
>
>>
>>
>> geir
>>
>>>
>>> Regards,
>>> Tim
>>>
>>
>
>
Re: [jchevm] APR issues
Posted by Jean-frederic Clere <jf...@gmail.com>.
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
>>
>
Re: [jchevm] APR issues
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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.
geir
>
> Regards,
> Tim
>
Re: [jchevm] APR issues
Posted by Tim Ellison <t....@gmail.com>.
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.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jchevm] APR issues
Posted by Tim Ellison <t....@gmail.com>.
Archie Cobbs wrote:
> Enrico Migliore wrote:
>>> 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.
>
> I think you two are in heated agreement. There are two different
> things: jchevm and classlib. For jchevm, it makes sense to port it
> to APR directly. For classlib (i.e., classlib's native code), it makes
> sense to port classlib's "portlib" layer to APR, rather than discarding
> portlib.
I'd hope that jchevm would consider using the portlib too; I have good
reason to believe that the portlib is well suited to the needs of a VM
implementation ;-)
It will be interesting to see how Artem's experiments with APR work-out.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jchevm] APR issues
Posted by Archie Cobbs <ar...@dellroad.org>.
Enrico Migliore wrote:
>> 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.
I think you two are in heated agreement. There are two different
things: jchevm and classlib. For jchevm, it makes sense to port it
to APR directly. For classlib (i.e., classlib's native code), it makes
sense to port classlib's "portlib" layer to APR, rather than discarding
portlib.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: [jchevm] APR issues
Posted by Enrico Migliore <en...@fatti.com>.
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.
>Regards,
>Tim
>
>
Enrico
Re: [jchevm] APR issues
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> 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 think I understand - right now, he can't compile.
Cygwin/WIndows will be good, as will the toolchain we are currently
using for the classlibrary, known as WTHWOTM "Whatever The Heck Was On
Tim's Machine"
>
>> 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 can't begin to express how strongly I support this.
Use APR as a portability assist - we have the portlib interface that
serves the needs of the VM, and you can implement it quickly
(hopefully?) using APR. If not, then we have a good opportunity to
offer enhancements to APR.
geir
Re: [jchevm] APR issues
Posted by Tim Ellison <te...@apache.org>.
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'?
> 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.
Regards,
Tim
--
Tim Ellison (tellison@apache.org)
IBM Java technology centre, UK.