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
