I've created ebuild for latest and greatest dev-java/rxtx package. It has been just released. Ebuild is tested, working on my machine:
x86, latest stable portage
Created attachment 78511 [details]
ebuild for rxtx
Created attachment 78517 [details]
ebuild for rxtx with a better SRC_URI
Author of rxtx advised a better url as SRC_URI
rxtx has been officialy published on rxtx.org!
Created attachment 87455 [details]
version bump with suggested SRC_URI from previously posted ebuilds
While bumping the ebuild, please consider the following:
rxtx stores its class in the package gnu. Some packages uses a javax package for the same classes.
rxtx tarball includes a script : rxtx-2.1-7pre17/contrib/ChangePackage.sh that allow switching between gnu and javax gerarchies.
It would be usefull if the jar package we build can contain both the gerarchies or if it's possible to change the gerarchy with a useflag.
the second proposal can be done simply with something like:
use javax && ./contrib/ChangePackage.sh javax
econf || die "Configuration failed"
emake || die "Make failed"
This may allow TinyOS removing the hard dep on ibm-jdk-bin.
It would probably be more useful to include both a version using gnu.* and a javax.*, rather than having it based on a USE flag. For example, what if you had one package that wanted gnu.*, and one that wanted javax.*? If you have the package name be determined by a USE flag, you wouldn't be able to have both of these packages installed at once.
another possible use flag would be "lockfiles" by setting --disable-lockfiles for configure accordingly (default would be true)
I looked at it, and it doesn't seem to be possible to include both interfaces in one package. Though it is easy to switch via the contrib script, you will end in two different JARs, but also two different JINI *.so's with the same same. While the JARs are no problem, the so's are.
So it would be better, if it is *really* needed, to make a 2nd package called "rxtx-javax". Then the packages can depend on it.
rxtx-184.108.40.206 is in CVS.
Please mark this (2.1.7) stable on amd64. It works fine and its predecessor is really crappy.