Joshua Sumali wrote:
> Matthias Klose wrote:
>>
>> - please use `transform' to install the binaries; just using 
>> gcc_suffix is
>>   inconsistant with current installation. Same for using GIJ_VERSION.
>>   
> I will look into this.
>> - symlinks for man pages are not installed. intended?
>>   
> I don't think this was part of java-gcj-compat, so it is not included 
> in my patch.
>> - + for jarname in jaas jce jdbc-stdext jndi jndi-cos jndi-dns ...
>>   I think this is fedora specific to support jpackage?  It doesn't hurt
>>   to have these symlinks. Maybe the same should be added for IcedTea?
>>
>> - Is the --with-arch-directory really needed? Shouldn't we just use the
>>   default.
>>   
> Yes, I believe this is necessary for different archs when building an 
> rpm. I can't remember off the top of my head, but for x86 the 
> directory is jre/lib/i386 and x86_64 is perhaps x86_64 or amd64. 
> Anyways, the java-1.5.0-gcj spec file shows configure with 
> "--with-arch-directory=%{_arch}".
>> +
>> jre_dir=java-${JAVA_VERSION}-${origin_name}-${JAVA_VERSION}.${BUILD_VERSION}${arch_suffix}/jre 
>>
>> +
>> sdk_dir=java-${JAVA_VERSION}-${origin_name}-${JAVA_VERSION}.${BUILD_VERSION}${arch_suffix} 
>>
>> +  jre_lnk=jre-${JAVA_VERSION}-${origin_name}
>> +  sdk_lnk=java-${JAVA_VERSION}-${origin_name}
>>
>> why using the long version at all? 
> I can't provide an exact answer, as I have just merged what was in 
> java-gcj-compat into this patch. Perhaps fitzsim could provide 
> insight, but I think for Fedora at least, we use the long version 
> (sdk_dir) for jvm installs.
>> afaik no packaging allows installation of two
>> such packages at the same time (with same jre_link and different 
>> jre_dir's). 
> What do you mean by "same jre_link and different jre_dir" exactly?
>> And
>> it makes it difficult for people writing into the ext subdirectory 
>> because this
>> changes across minor version upgrades
>> - The new configure options should be documented in gcc/doc/install.texi
>>   (and maybe something about the jpackage compatible (?) layout).
>>   
> Sure, I can do this.
>> - what is the rationale of --with-jvm-jar-dir ?
>>   
> It's to provide some control as to where we're installing the jar 
> symlinks. Default is /usr/lib/jvm-exports, but I'm not sure if this is 
> consistent across all distros, so I think it's nice to have an option 
> to change this location.
>> Matthias
>>   
>
Hi,

Please see the two (updated) patches. The updated patch for the 
"Packager files" thread is now part of the sdk-home patch attached here, 
since I had to modify configure.ac to generate those packager files this 
time around.

gcc-install-and-docs.patch creates man and info pages for aot-compile 
and rebuild-gcj-db, and also documents the new install options 
(--enable-java-home, --with-arch-directory, --with-python-dir) as 
requested by Matthias.
gcc-libjava-sdk-home-update.patch is mostly the same as the first patch 
I posted here, except with these main changes:

    - aot-compile and rebuild-gcj-db are now installed in $bindir
    - if --with-python-dir is not specified (say, in a regular upstream 
build) , classfile.py and aotcompile.py are installed in 
$(prefix)/share/python. Otherwise, those Python modules will be 
installed in the path specified with --with-python-dir. I modified 
aot-compile -> aot-compile.in to append whichever path classfile.py and 
aotcompile.py was installed in, so that it can actually find these 
modules (it wouldn't look in $(prefix)/share/python by default).
    - the SDK symlinked binaries, as well as aot-compile and 
rebuild-gcj-db are now `transformed' as requested by Matthias.

Outstanding issues:
1. @Matthias, I'm still not sure what you mean by "Same for using 
GIJ_VERSION". Also, the issue about "why using the long version at all?"
2. rebuild-gcj-db doesn't have a licence header on the top of the 
file... is this required? And if so, what's the right thing to do about it?

Josh