Rodrigo,
An eloquent expression of the sentiments of
many experienced developers! I selected GCC just
for this reason, it is ubiquitously used on many
platforms. Can we use code compiled with CygWin's
GCC compiler on a native Windows platform? I've
done Win32 apps with GCC and MSVC both, but I've
not tried a mix and match between CygWin and
Windows with MSVC and GCC. Comments?
Anyone else have some experience with this issue?
I still think we should see what everyone thinks
about MSVC in particular.
Dan Lydick
-----Original Message-----
From: Rodrigo Kumpera <[EMAIL PROTECTED]>
Sent: Oct 20, 2005 12:40 PM
To: harmony-dev@incubator.apache.org
Subject: Re: Small problems building under cygwin
Dan,
Suporting multiple SO and hardware configurations is going to be PITA,
adding compiler to this mix might be overkill. It's true that many
specialized compiler generate better code than gcc for their platform,
f.e. ICC, but does that justify the extra effort?
I mean, there are a LOT of stuff we'll need to support many compilers:
libraries have diferent performance problems and bugs; compilers have
diferent extensions, standards compliance, assembly sintax and bugs.
Assembly, for one, is going to be a big issue if we start using native
threads and need to use memory barriers, we will have the exact same
x86 code in at&t and intel styles.
It's doable, but will require a LOT of effort to be done. Anyway, I
don't see much harm in requiring non-linux developers to have instaled
the gcc toolchain and a bourne shell interpreter, that's a lot less
than many complex projects require for the build enviroment.
But even then, I'm biased on this subject, as I cannot survive a
windows machine without cygwin and don't care much for anything else
but linux.
Have said that, I think having build.sh converted to a .bat script is
not necessary, only maybe as a subset, that supports only win32/64 on
MSVC.
On 10/20/05, Apache Harmony Bootstrap JVM <[EMAIL PROTECTED]> wrote:
>
> Rodrigo,
>
> Thanks for your help with these items. I think that
> it should be a simple matter to have 'config.sh' set
> a 'win32' path. In fact, there should probably be
> a map function for that include path so that each
> configuration can set that subdirectory name to
> whatever Sun declares it to be for that platform
> instead of depending on the OS platform name.
>
> The '__int64' issue is an interesting one! That's
> why we're trying out all these porting things. To
> me, the solution depends partly on a matter of
> build policy, namely, which compilers do we use?
> I think that there is a case to be made for supporting
> MSVC in addition to GCC since it has a large installed
> base, and a Windows version of the build scripts
> should be able to support both. I suggest that we
> could have the compiler as one of the configuration
> options in 'config.sh' for Windows and CygWin, also
> for the Windows .BAT file equivalent. What do you
> think?
>
>
> Dan Lydick
>
>
> -----Original Message-----
> From: Rodrigo Kumpera <[EMAIL PROTECTED]>
> Sent: Oct 19, 2005 5:42 PM
> To: harmony-dev <harmony-dev@incubator.apache.org>
> Subject: Small problems building under cygwin
>
> I've found a small issue while building under cygwin.
>
> I'm using j2sdk 1.4 and gcc 3.4.4 (cygwin). The problems are when
> building the jni stuff.
>
> First it included on gcc find patch "j2sdk\include\cygwin", but it
> should be "j2sdk\include\win32".
>
> Second is when building the included file "jni_md.h" breaks everything
> as it defines jlong as "__int64" and not "long long".
>
> Fixing both is pretty easy, either edit config/config_opts_always.gcc
> or rename the directory from win32 to cygwin.
>
> The second you can either edit jni_md.h and change "__int64" to "long
> long" or include a define directive, or something like this, in
> config/config_opts_always.gcc.
>
>
> I'm not sure what would be the best way to fix this on build.sh, as
> the first issue is related to build enviroment and the second about
> incompatible compilers ("__int64" works on MSVC and ICC but not gcc)
>
> []s
> Rodrigo
>
>
>
>
> Dan Lydick
>
Dan Lydick
