Community
Participate
Working Groups
Hello, I have several problem with compiling the native parts of eclipse. Two of them aore in Bug: #71636 and Bug: #71633. Another one is, that ther eis no configure, which figures out my current configuration and a resulting makefile, which compiles the native parts in one go. So, I make a wish for such a thing along the build.sh and build.xml file in root directory of the eclipse source builds. Nice greetings, Jan
Adding dependcies on mentioned Bugs
*** Bug 43119 has been marked as a duplicate of this bug. ***
Source builds >= N20050127 will have support for recompiling native libraries on solaris-gtk-x86. You can also use the -compilelibs parameter to force the recompilation which running the build script. Since we don't have the resources to test this configuration, please advise us of any changes required to the scripts so they can be incorporated into the source builds.
Created attachment 18074 [details] adds native lib compilation to pde.build Hi Kim, The logic in the sourceBuild build.xml only builds SWT and launcher; other fragments with native code are still not built. This patch gives the pde.build plugin the ability to generate build.xmls that will call either a Makefile or an ant script to compile the native libraries. The fragment must specify which method to use in the build.properties file (see the examples in o.e.core.resources.linux and o.e.update.core.linux). An alternate solution would be to add the logic to build this stuff in the sourceBuild build.xml but I think having it built in the generated build.xmls is better because it will allow sourceBuilds to be easily made for plugins that have native code (ie CDT). The main problem with this patch that all fragments are built regardless of which platform the build is running on. My personal opinion is that this behaviour is a bug, but I would like some comments on my approach before I attempt to fix this bug. I suspect that Pascal might have some comments. Thanks.
Created attachment 18075 [details] adds native lib building to org.eclipse.resources.linux
Created attachment 18076 [details] adds native lib building to org.eclipse.update.core.linux
I would love to see this patch (or some similar one) applied as we currently have to special-case all the native libs in our RPM builds.
Any news here?
Hi Andrew, I've decided to fix the problem I decribed in comment #4 without comments from some Eclipse developers. Perhaps a more complete solution will draw some interest. I'll post back when I have something.
I think this should have been assigned to releng.
Or PDE build, I'm not sure... At least I don't think Ben's proposal was for SWT. :)
I forgot to cc myself on the bug when I commented earlier. This is why I didn't respond to the comments. Moving to pde build since the suggestions are for their code base.
Thanks for punting this to the correct place. I'd still like to finish this up before anybody seriously takes a look at it. I'll try to have something within a week.
Reading this bug again made me realize that I hijacked it. I think Jan wanted swt to be autotooled, while I want a generic build mechanism for fragments that have native code. I guess this is why it was initially assigned to an swt developer. Sorry for the confusion. Should I file a new bug about my feature request or should I file a new bug describing Jan's initial request?
Since your patch I think would be fine for what Jan wanted I think you should leave this bug for PDE build and (if desired) open a new bug against SWT for autoconf'ing the SWT download.
The bug is already open: Bug:#71636. The problem is, that the SWT Scripts assume that it is build on a special host. Autotooling would be really cool, but it's mostly enough if you don't need to patch everything to get eclipse packaged.
Looking at the patch again, the problem is that all fragments are built regardless of which os/arch/ws you are building on. For example, if a fragment has different native code for x86 and x86_64, both versions for the native code would try to build. Obivously this won't work. To get around this, the generated build.xml for features could be modified to only build fragments if they have been written for the os/arch/ws that the build is happening on. Here's an example of what a generated build.xml could look like (note I didn't actually test this): <target name="all.plugins" depends="init"> ... <!-- example of how a plugin would be called --> <ant antfile="build.xml" dir="../../plugins/org.eclipse.platform.doc.user" target="${target}" /> ... <!-- example of how a fragment would be called --> <condition property="org.eclipse.swt.gtk--x86-linux-gtk"> <and> <equals arg1="${arch}" arg2="x86" /> <equals arg1="${os}" arg2="linux" /> <equals arg1="${ws}" arg2="gtk" /> </and> </condition> <antcall target="org.eclipse.swt.gtk--x86-linux-gtk" /> <!-- end fragment call --> ... </target> <target name="org.eclipse.swt.gtk--x86-linux-gtk" if="org.eclipse.swt.gtk--x86-linux-gtk"> <ant antfile="build.xml" dir="../../plugins/org.eclipse.swt.gtk" target="${target}" /> </target> IMO, this is a little awkward so it might be worthwhile to see if the "if" task from ant-contrib could be used. If this route is chosen, than we could use the cc task from this collection too. You're probably very busy right now so this is most likely not on the radar for 3.1. If/when you are interested in this, please comment as I would be interested in completing this if I don't have too much going on.
I haven't reviewed any patch. It is actually the first time that I see this bug. Anyway, to follow the logic of pde build, the code should be compiled by the "build.jars" target of the build.xml of plugins or fragments. This task is actually invoked from the build.xml of the feature containing the plugin. This call has the proper arguments in terms of os / ws / arch. In an example, you mention that the same plugin may contain code for multiplearchitectures, I think this is fine as long as the plugin has different name once built, otherwise this is wrong. If you have some code that can fit several platform, it is fine to have the code in one plugin for maintenance purpose but, from a binary point of view you should end up with as many plugins as you have platform. This is why SWT has been recently changed. With following the two previous recommendation no code change is required in pde build.
It should be possible to do this currently using the customCallbacks that were introduced in 3.2. As Pascal mentioned, the build.jars target will be invoked with proper os, arch and ws values. (Might need to set customBuildCallbacks.inheritall to inherit these properties) There are 3 callbacks within the build.jars target (pre.<libraryName>, post.compile.<libraryName> and post.<libraryName>. The callbacks are in an ant script that is provided by the plug-in and could do whatever you want.
Building natives is hooked in the tycho build now. Closing this one as wontfix.
