This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: javac on cygwin


On Sat, Jan 04, 2003 at 04:20:36PM -0800, Randall R Schulz wrote:
>At 14:17 2003-01-04, Shankar Unni wrote:
>>Randall R Schulz wrote:
>>
>>>Javac is not particularly special. It is a Windows-native program, and as 
>>>such requires absolute file and directory names be provided in Windows 
>>>format (forward slashes are OK, but drive letters are required and the 
>>>Cygwin notion of root is completely unknown to such programs).
>>
>>Javac is a pure java program. The "windows executable" is only there as a 
>>thin native wrapper that launches sun.tools.javac.Main.
>
>That may be true, but it's irrelevant. Its external interface via its 
>command line options follows the Windows conventions. That's all that 
>matters. It is a Windows executable for all intents and purposes.
>
>
>>The bigger problem is that Sun JRE is compiled to the native Win32 API, 
>>not to cygwin, so *any* Java programs running in the Sun JRE will never 
>>understand cygwin mount points.
>
>Yes, of course. That's hardly surprising.
>
>
>>In theory, someone could invest in the effort to port, say, the Linux port 
>>of the Sun JRE to cygwin, but it would be a huge effort.
>>
>>Igor's idea (wrappers that run cygpath -m on the paths being passed to 
>>Java) would be the best approach in this situation, especially for 
>>well-known Java programs like "javac".
>
>That's what I do. I have a generic one that converts anything that "looks 
>like" a file name via cygpath. It's not fool-proof, but the criteria for 
>converting names could be refined.
>
>The alternative is a target-specific script that understands what all the 
>arguments options and option arguments are and converts them as needed.

I remember speculating at one point about creating wrappers to the win32
functions like CreateFile, MoveFile, etc.  which would understand cygwin
paths.  You could theoretically modify an .exe to load cygwin1.dll and
use the wrapper functions.  Or you could use some of Windows hook
facilities to do that.

I don't think my idea met with much enthusiasm when I mentioned it, but
I always thought it would be an interesting exercise.  It wouldn't help
for programs which actually do parsing on input file specs outside of
the standard Windows API, though.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]