kpriv/pkgsrc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
pkgsrc/lang/japhar/PLIST

152 lines
3.5 KiB
Text
Raw Normal View History

Introduce new framework for handling info files generation and installation. Summary of changes: - removal of USE_GTEXINFO - addition of mk/texinfo.mk - inclusion of this file in package Makefiles requiring it - `install-info' substituted by `${INSTALL_INFO}' in PLISTs - tuning of mk/bsd.pkg.mk: removal of USE_GTEXINFO INSTALL_INFO added to PLIST_SUBST `${INSTALL_INFO}' replace `install-info' in target rules print-PLIST target now generate `${INSTALL_INFO}' instead of `install-info' - a couple of new patch files added for a handful of packages - setting of the TEXINFO_OVERRIDE "switch" in packages Makefiles requiring it - devel/cssc marked requiring texinfo 4.0 - a couple of packages Makefiles were tuned with respect of INFO_FILES and makeinfo command usage See -newly added by this commit- section 10.24 of Packages.txt for further information.
2002-02-18 16:14:00 +01:00
@comment $NetBSD: PLIST,v 1.2 2002/02/18 15:14:26 seb Exp $
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libarch.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libarch.la
lib/libarch.so
lib/libarch.so.1
lib/libarch.so.1.0
lib/libffi.so
lib/libffi.so.2
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libffi.so.2.3
lib/libffi.la
lib/libffi.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libjni.so
lib/libjni.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libjni.so.1.0
lib/libjni.la
lib/libjni.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libjvmdi.so
lib/libjvmdi.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libjvmdi.so.1.0
lib/libjvmdi.la
lib/libjvmdi.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libruntime.so
lib/libruntime.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libruntime.so.1.0
lib/libruntime.la
lib/libruntime.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libjaphar_lang.so
lib/libjaphar_lang.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libjaphar_lang.so.1.0
lib/libjaphar_lang.la
lib/libjaphar_lang.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libjaphar_reflect.so
lib/libjaphar_reflect.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libjaphar_reflect.so.1.0
lib/libjaphar_reflect.la
lib/libjaphar_reflect.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libjaphar_io.so
lib/libjaphar_io.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libjaphar_io.so.1.0
lib/libjaphar_io.la
lib/libjaphar_io.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libjaphar_net.so
lib/libjaphar_net.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libjaphar_net.so.1.0
lib/libjaphar_net.la
lib/libjaphar_net.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libjaphar_security.so
lib/libjaphar_security.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libjaphar_security.so.1.0
lib/libjaphar_security.la
lib/libjaphar_security.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libjaphar_util.so
lib/libjaphar_util.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libjaphar_util.so.1.0
lib/libjaphar_util.la
lib/libjaphar_util.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libjaphar_zip-1.1.so
lib/libjaphar_zip-1.1.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libjaphar_zip-1.1.so.1.0
lib/libjaphar_zip-1.1.la
lib/libjaphar_zip-1.1.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libjaphar_zip.so
lib/libjaphar_zip.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libjaphar_zip.so.1.0
lib/libjaphar_zip.la
lib/libjaphar_zip.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libjaphar_sysresource.so
lib/libjaphar_sysresource.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libjaphar_sysresource.so.1.0
lib/libjaphar_sysresource.la
lib/libjaphar_sysresource.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libjaphar_agent.so
lib/libjaphar_agent.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libjaphar_agent.so.1.0
lib/libjaphar_agent.la
lib/libjaphar_agent.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libjaphar_mmedia.so
lib/libjaphar_mmedia.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libjaphar_mmedia.so.1.0
lib/libjaphar_mmedia.la
lib/libjaphar_mmedia.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libjaphar_awt.so
lib/libjaphar_awt.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libjaphar_awt.so.1.0
lib/libjaphar_awt.la
lib/libjaphar_awt.a
The way that shared objects were handled in the PLISTs and bsd.pkg.mk was out of date - it was based on a.out OBJECT_FMT, and added entries in the generated PLISTs to reflect the symlinks that ELF packages uses. It also tried to be clever, and removed and recreated any symbolic links that were created, which has resulted in some fun, especially with packages which use dlopen(3) to load modules. Some recent changes to our ld.so to bring it more into line with other Operating Systems also exposed some cracks. + Modify bsd.pkg.mk and its shared object handling, so that PLISTs now contain the ELF symlinks. + Don't mess about with file system entries when handling shared objects in bsd.pkg.mk, since it's likely that libtool and the BSD *.mk processing will have got it right, and have a much better idea than we do. + Modify PLISTs to contain "ELF symlinks" + On a.out platforms, delete any "ELF symlinks" from the generated PLISTs + On ELF platforms, no extra processing needs to be done in bsd.pkg.mk + Modify print-PLIST target in bsd.pkg.mk to add dummy symlink entries on a.out platforms + Update the documentation in Packages.txt With many thanks to Thomas Klausner for keeping me honest with this.
2001-01-04 16:10:17 +01:00
lib/libjaphar_fontmanager.so
lib/libjaphar_fontmanager.so.1
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
lib/libjaphar_fontmanager.so.1.0
lib/libjaphar_fontmanager.la
lib/libjaphar_fontmanager.a
bin/japhar
bin/japharh
bin/japhard
bin/jar
bin/jarsigner
bin/javac
bin/javah
bin/jdb
bin/javadoc
bin/javakey
bin/javap
bin/appletviewer
bin/native2ascii
bin/rmic
bin/rmid
bin/rmiregistry
bin/serialver
bin/tnameserv
bin/policytool
bin/keytool
bin/extcheck
bin/japhar-config
include/japhar/private/ClazzFile.h
include/japhar/private/alloc.h
include/japhar/private/array-class.h
include/japhar/private/arrays.h
include/japhar/private/class-repository.h
include/japhar/private/classpath.h
include/japhar/private/dynamic_loading.h
include/japhar/private/exceptions.h
include/japhar/private/gc.h
include/japhar/private/getopt.h
include/japhar/private/init.h
include/japhar/private/interp.h
include/japhar/private/log.h
include/japhar/private/native-threads.h
include/japhar/private/method.h
include/japhar/private/compat.h
include/japhar/private/objects.h
include/japhar/private/op_stack.h
include/japhar/private/primitive-class.h
include/japhar/private/qop.h
include/japhar/private/resolve.h
include/japhar/private/sig.h
include/japhar/private/signals.h
include/japhar/private/util.h
include/japhar/private/zipfile.h
include/japhar/jnitypes.h
include/japhar/jni.h
include/japhar/jniint.h
include/japhar/jvmdi.h
include/japhar/jvmdiint.h
include/fficonfig.h
include/ffi.h
include/ffi_mips.h
Introduce new framework for handling info files generation and installation. Summary of changes: - removal of USE_GTEXINFO - addition of mk/texinfo.mk - inclusion of this file in package Makefiles requiring it - `install-info' substituted by `${INSTALL_INFO}' in PLISTs - tuning of mk/bsd.pkg.mk: removal of USE_GTEXINFO INSTALL_INFO added to PLIST_SUBST `${INSTALL_INFO}' replace `install-info' in target rules print-PLIST target now generate `${INSTALL_INFO}' instead of `install-info' - a couple of new patch files added for a handful of packages - setting of the TEXINFO_OVERRIDE "switch" in packages Makefiles requiring it - devel/cssc marked requiring texinfo 4.0 - a couple of packages Makefiles were tuned with respect of INFO_FILES and makeinfo command usage See -newly added by this commit- section 10.24 of Packages.txt for further information.
2002-02-18 16:14:00 +01:00
@unexec ${INSTALL_INFO} --delete %D/info/japhar.info %D/info/dir
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
info/japhar.info
Introduce new framework for handling info files generation and installation. Summary of changes: - removal of USE_GTEXINFO - addition of mk/texinfo.mk - inclusion of this file in package Makefiles requiring it - `install-info' substituted by `${INSTALL_INFO}' in PLISTs - tuning of mk/bsd.pkg.mk: removal of USE_GTEXINFO INSTALL_INFO added to PLIST_SUBST `${INSTALL_INFO}' replace `install-info' in target rules print-PLIST target now generate `${INSTALL_INFO}' instead of `install-info' - a couple of new patch files added for a handful of packages - setting of the TEXINFO_OVERRIDE "switch" in packages Makefiles requiring it - devel/cssc marked requiring texinfo 4.0 - a couple of packages Makefiles were tuned with respect of INFO_FILES and makeinfo command usage See -newly added by this commit- section 10.24 of Packages.txt for further information.
2002-02-18 16:14:00 +01:00
@exec ${INSTALL_INFO} %D/info/japhar.info %D/info/dir
Import japhar, a Java Virtual Machine, currently JDK 1.1.5-level, into the NetBSD packages collection.
1999-10-28 11:51:43 +02:00
@dirrm include/japhar/private
@dirrm include/japhar
Reference in a new issue Copy permalink