Ivan Popov wrote:
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?
Yes. (This feature has now been there for months...)
There's a flag "deploy.canonical.flag" that you can specify on the
command line or more commonly, put in the
build/drlvm.properties
file which has the output go into the directory that you noted above
(deploy/...)
I made the mistake of not defaulting that flag to true, which I will fix
now. If you don't like it, turn it off. :)
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.
Yes, we know. That's why we moved them there.
But the "canonical deploy directory" feature of the DRLVM build made
everything work.
Again, the problem was that the flag wasn't set to do this by default,
but it will going forward.
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.
We were planning to get them out of DRLVM , but your idea is a good one.
I'd like to see more things move to common_resources, if that makes sense.
geir
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
