6 messages in org.freebsd.freebsd-eclipseEclipse 3.1: no swt-pi-gtk-3138| From | Sent On | Attachments |
|---|---|---|
| Mario Sergio Fujikawa Ferreira | Aug 29, 2005 6:07 pm | |
| Stephane E. Potvin | Aug 29, 2005 8:09 pm | |
| Panagiotis Astithas | Aug 29, 2005 9:48 pm | |
| Stephane E. Potvin | Aug 30, 2005 12:15 pm | |
| Mario Sergio Fujikawa Ferreira | Aug 30, 2005 4:02 pm | |
| Panagiotis Astithas | Aug 31, 2005 9:17 pm |
| Subject: | Eclipse 3.1: no swt-pi-gtk-3138 | |
|---|---|---|
| From: | Panagiotis Astithas (pa...@ebs.gr) | |
| Date: | Aug 31, 2005 9:17:14 pm | |
| List: | org.freebsd.freebsd-eclipse | |
Mario Sergio Fujikawa Ferreira wrote:
Hi,
Well, I agree that only one instance of swt should be ever lying around. Or, at least, that they not CONFLICT with one another since I need eclipse to build azureus but only swt to run it which means I would have a hell of a dependency problem otherwise.
Well, for those wondering about an example. I did a crude hack to azureus to get it going. The port still needs polishing but it is good enough so that you can try any of the mentioned solutions.
I, for one, would prefer that the eclipse port would extract the .so files somewhere rather than incarnating yet another port since I also need the swt*jar files which are part of eclipse. We wouldn't gain much from another port (saving run time dependencies I mean), we would require both in the end.
Port sample,
http://people.FreeBSD.org/~lioux/azureus.tgz
Regards,
Just to clear this one up, an swt port would contain every swt*.jar and every libswt*.so you see in eclipse.
I see that the linux distribution of azureus bundles swt along. That means that they are not concerned with the assorted bloat. That is to be expected, I guess.
Let me try to make an evaluation of the problem. The use cases I can think of are these:
1. users who need eclipse and not azureus and friends 2. users who need azureus, etc but not eclipse 3. users who need both eclipse and swt-based apps
These are the solutions I see thus far:
a. have a swt port besides the eclipse port b. keep only the eclipse port but tweak its swt jars c. keep only the eclipse port but tweak with azureus/etc. build process
Solution a satisfies use cases 1 and 2. Use case 3 would be completely satisfied only if we avoid keeping two copies of swt.
Solution b satisfies use cases 1 and 3. Use case 2 would have unnecessary bloat.
Solution c satisfies use cases 1 and 3. Use case 2 would have unnecessary bloat.
It seems that solution a would be ideal, provided that we can solve the eclipse/swt dependency issues. I would really like to avoid undoing the new standard eclipse plugin structure (single jars), since that would make it different from the package people would get from eclipse.org (in the not-too-distant future). I'm trying to invent some extra logic in the ports Makefiles, like "if we have eclipse, depend on it instead of swt", or "if eclipse exists mark swt as IGNORE", etc. If anyone has any ideas, I'm all ears.
Alternatively, if you know how to specify the location of a native library to be in an archive, please speak up!
Cheers,
Panagiotis