Danek Duvall wrote: > I'm sponsoring the following case for Harshal Patil. This case is intended > to support the Azureus (soon to be Vuze) bittorrent client, the case for > which should be running soon. It would also enable Eclipse to be > integrated.
Yeah, I've spent far to much time in the last two weeks trying to build these libs for exactly that reason! > /usr/lib/swt/swt.jar Why are we hiding the main swt interface here ? Should this be somewhere more generic like /usr/share/lib/java/ > /usr/lib/swt/swt-debug.jar > /usr/lib/swt/libswt-pi-gtk-3349.so > /usr/lib/swt/libswt-gtk-3349.so > /usr/lib/swt/libswt-gnome-gtk-3349.so > /usr/lib/swt/libswt-cde-gtk-3349.so > /usr/lib/swt/libswt-cairo-gtk-3349.so > /usr/lib/swt/libswt-awt-gtk-3349.so > /usr/lib/swt/libswt-atk-gtk-3349.so > > Since this is a shared lib, the numbers before .so don't matter.. even if > we later upgrade this lib, all the apps depending on it will not be > affected. What those apps will look for is to load libs like swt-atk-gtk > etc. As Danek already pointed out the statement is clearly false. I'm also VERY concerned about this since the motivation for this case is Vuze which auto updates itself. I'm concerned that some future version of an autoupdate of Vuze will need a different version of SWT. How will that be dealt with [ Not the Vuze update but the future version of libswt ] ? Unless there is a plan to have multiple versions of SWT installed I see no reason to have the -3349 in the file names. Particularly since it is NOT present in the main swt.jar file; meaning it isn't possible with the layout presented in this case to have multiple versions of SWT. So just drop the -3349. What versions of the JRE does this SWT build support ? -- Darren J Moffat
