1 |
Petteri Räty wrote: |
2 |
|
3 |
> http://lists.debian.org/debian-java/2003/06/msg00005.html |
4 |
|
5 |
This was what I feared, but hoped was not the case. |
6 |
|
7 |
> I like more the idea of making symlinks to /usr/include. That would be |
8 |
> more in line with our switching of vms for compile. |
9 |
|
10 |
I don't see how symlinks in /usr/include can work. If there are two |
11 |
users on a system, each with his own prefered VM, how can we export two |
12 |
sets of symlinks for that system? |
13 |
|
14 |
Furthermore, it will not be possible to switch the system VM's symlink |
15 |
during emerge. Consider the situation where root merges a few Java |
16 |
packages as part of a maintenance cycle, while a regular user (who may |
17 |
not have set their default VM) compiles a Java program which uses JNI. |
18 |
The /usr/include/jni.h seen by the user's compilation may flip between |
19 |
various possible jni.hs, making his program break in mysterious ways. |
20 |
|
21 |
Of course you can argue that this is an unlikely situation, but what if |
22 |
root stops the merge with a ctrl-C? Then the /usr/include/jni.h will be |
23 |
completely wrong, in this scheme. |
24 |
|
25 |
> What is espicially |
26 |
> bad about adding them with -I to CFLAGS? That would be the easiest way |
27 |
> to ensure we are using the jni.h we thought. It would also be better |
28 |
> if gjc did not install jni.h to /usr/include but that is an upstream |
29 |
> issue I think. |
30 |
|
31 |
As you pointed out yourself, some packages try to be smart and find the |
32 |
jni.h themselves. If they use something like if [ -x ${path}/jni.h ], |
33 |
putting an -I in CFLAGS won't help much, and the configure script will |
34 |
probably stop with an error. |
35 |
|
36 |
If the package tries to find the jni.h by compiling with various -I |
37 |
options, we may get lucky. The only remaining problem then is ensuring |
38 |
that we in fact do _not_ have a gcj-installed jni.h in /usr/include, |
39 |
since that may take precedence. |
40 |
|
41 |
|
42 |
-- Karl T |
43 |
-- |
44 |
gentoo-java@g.o mailing list |