Makefiles for JPDA component in jdktools pass the following include directory to native compiler:
-I$(HY_DRLVM)\jdk\include which is expanded to <…>\trunk\working_vm\build\deploy\jdk\include However, default build for working_vm creates DRLVM build in a platform dependent directory: <…>\trunk\working_vm\build\win_ia32_msvc_debug\deploy\jdk\include That's why header files from DRLVM were not found in my build. Do you have DRLVM build in a platform independent directory? We could fix makefiles to look into platform dependent DRLVM build directory or look into VM sources (working_vm\vm\include). But, since JNI/JVMTI headers are VM-independent, it's better to get them from classlib, not from DRLVM. However, now we have similar header files in classlib and DRLVM sources and need to synchronize them in case of any changes. I still think it's better to move these headers to common_resources/include and use the same headers in both classlib and DRLVM builds. Thanks. Ivan On 12/18/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Tim Ellison wrote: > Geir Magnusson Jr. wrote: >> If you haven't yet, let me know and I will - I'm confused how he can't >> build and want to figure that out. > > I did already (r488244). Apologies if that was too quick to figure out > the issue. I also don't grok why the build would not have worked from > the DRLVM copy, but figured it makes sense to unify on a single set of > includes for jni/jvmti. > No worries - thanks for doing it. Yes, there's no argument there - we need one copy. I'll go now and clean up anything that depends on it, then remove the DRLVM copies. I just wanted to figure out why Ivan thought he couldn't build w/o this change. > For now the classlib version is a copy of the DRLVM files, giving folk > time to migrate the build scripts etc. Yep geir
