Bugzilla – Full Text Bug Listing
| Summary: | ImageCapture.java depends on internal swt fragments; cannot be compiled on linux | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Nick Boldt <nboldt> |
| Component: | VE | Assignee: | VE Bugzilla inbox <ve-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jeff.myers, richkulp, yves.yang |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 270849 | ||
|
Description
Nick Boldt
Failing that, should I attempt to compile this by including all three (Win, Max, Linux) Eclipse platforms in the runtime in which the build runs? (In reply to comment #1) > Failing that, should I attempt to compile this by including all three (Win, > Max, Linux) Eclipse platforms in the runtime in which the build runs? > I think VE is never compiled in Linux and Mac. It can be compiled only in Windows. (In reply to comment #2) > (In reply to comment #1) > > Failing that, should I attempt to compile this by including all three (Win, > > Mac, Linux) Eclipse platforms in the runtime in which the build runs? > I think VE is never compiled in Linux and Mac. It can be compiled only in > Windows. That's a problem given that build.eclipse.org is a ppc linux box, and I run linux x86 here too. I have a virtual Win XP I can use for testing, but really, this ought to be able to build anywhere. Does VE only *run* on Windows, too? I'd assumed it had cross-platform use, and therefore could be compiled cross-platform too. (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Failing that, should I attempt to compile this by including all three (Win, > > > Mac, Linux) Eclipse platforms in the runtime in which the build runs? > > I think VE is never compiled in Linux and Mac. It can be compiled only in > > Windows. > That's a problem given that build.eclipse.org is a ppc linux box, and I run > linux x86 here too. I have a virtual Win XP I can use for testing, but really, > this ought to be able to build anywhere. > Does VE only *run* on Windows, too? I'd assumed it had cross-platform use, and > therefore could be compiled cross-platform too. No, VE does run on all platforms. It is only the compilation issue for Windows. There are some codes can be compiled only on Windows, which is used only for Windows. For other platforms, the codes are developed in reflection. I have just committed my modifications in reflection for Windows in /cvsroot/tools/org.eclipse.ve/plugins/org.eclipse.ve.swt. Please check it out. The Linux and Mac versions rely on native libraries to perform the image captures on their respective platforms. These native libraries were not part of the build - we compiled them on their native platforms and checked in the .so as binaries to include as part of the VE build. I developed the native libraries for the Mac support. Let me know if you need any help to change the way they're built. I'm guessing that it'll probably be easiest to maintain the status quo in terms of the image capture code (except with making windows use reflection too) until it breaks. (In reply to comment #5) > The Linux and Mac versions rely on native libraries to perform the image > captures on their respective platforms. These native libraries were not part of > the build - we compiled them on their native platforms and checked in the .so > as binaries to include as part of the VE build. > I developed the native libraries for the Mac support. Let me know if you need > any help to change the way they're built. I'm guessing that it'll probably be > easiest to maintain the status quo in terms of the image capture code (except > with making windows use reflection too) until it breaks. Thanks for the offer. The problem is not in Mac version. It is in Windows version. I have changed it in reflection. By the way, I have met a problem with Mac Bug 268614. I appreciate if yoiu can takea look at it. As a workaround, I've added the win32 swt.jar into the classpath of the plugin, under a new lib/ folder. Plugin now compiles in my workspace on Linux. (In reply to comment #7) > As a workaround, I've added the win32 swt.jar into the classpath of the plugin, > under a new lib/ folder. Plugin now compiles in my workspace on Linux. > I just modified and committed the modifications for unix and unix64. You can check them out. (In reply to comment #8) > (In reply to comment #7) > > As a workaround, I've added the win32 swt.jar into the classpath of the plugin, > > under a new lib/ folder. Plugin now compiles in my workspace on Linux. > > > > I just modified and committed the modifications for unix and unix64. You can > check them out. With these changes and a repaired .classpath, this plugin compiles. Ultimately, we'll have to ensure we test w/ newer (eg., Eclipse 3.5) versions of the swt jar, but for now this is done. Can you take the Reflection code back out? It will slow down image capture because VE does that very very often. If all Nick had to do was put the jar in the class path then you shouldn't need reflection. Thanks, Rich Are you sure it is due to the reflection code? The reflection is already used in MAC OS. And the code is optimized. I have made a quick test, I cannot see any visible difference. Have you observed some? I just don't like reflection when not needed. Eclipse compiles their builds on Linux too, even the Windows SWT stuff. They don't compile the SWT code on Windows. We shouldn't either. Nick said it was just a simple put of the jar in the classpath. Reflection just complicates things at runtime when not needed. Especially since the most heavy usage of VE will be on Windows, not Linux, so it should be optimized for Windows. In fact the way we compiled the code when VE first came out was we compiled on Linux but we used an Eclipse Windows SDK as the target. (In reply to comment #12) > I just don't like reflection when not needed. Eclipse compiles their builds on > Linux too, even the Windows SWT stuff. They don't compile the SWT code on > Windows. We shouldn't either. Nick said it was just a simple put of the jar in > the classpath. Reflection just complicates things at runtime when not needed. As for Java reflection, as general principe, I totally agree with you. But I worry about any exception codes or workarround solutions in a production environment, which increases the difficulties of maintain. > Especially since the most heavy usage of VE will be on Windows, not Linux, so > it should be optimized for Windows. I don't think the code in reflection is obviously slow. > In fact the way we compiled the code when VE first came out was we compiled on > Linux but we used an Eclipse Windows SDK as the target. Since it is about the deployment issue, I leave the decision to Nick to keep the current codes or go back to previous version. Revert it; if it breaks the build, we'll put it back. If it doesn't, as I suspect, then problem solved. :) I don't know enough about the internals of VE to know whether this change is required for some other reason, or if in fact it is a performance hit. I only use Windows for cross-platform testing, and will not likely be a heavy VE user, so I'm really not qualified to tell you whether or not to keep the code from anything more than a "does the build compile?" point of view. |