Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [linuxtools-dev] Eclipse Build 0.6.0?

On Tuesday, 10 August 2010, at 6:18 pm, Niels Thykier wrote:
> On 2010-08-10 22:33, Matt Whitlock wrote:
> > 	4. Strip the building of libgnomeproxy from build.xml on x86 if the user has the "gnome" USE flag disabled.
> 
> I believe it should be fairly easy to make a patch for this to allow a
> property to disable the building of libgnomeproxy. If you are interested
> in it, feel free to file a bug against LinuxTools and assign me to it
> (as I recall I wrote the libgnomeproxy part).

I'm not too interested.  The current workaround on Gentoo works sufficiently cleanly.  Writing the Eclipse ebuild was just a means to an end for me since I use Gentoo exclusively and need Eclipse for work; I'm not even officially a Gentoo developer.

> > 	5. Strip the building of the SWT native libraries from build.xml since SWT is installed independently on Gentoo.
> 
> I could be interest in e-b supporting this as well. There has been some
> interest in doing something similar in Debian. Feel free to file a bug
> and assign me to this one as well and I will look into a similar solution.

I'll file a bug that shows what the current Gentoo ebuild does to disable building SWT.  I don't think it's quite complete as of 3.6, as the build process now spits out a bunch of errors about SWT packages, but it doesn't seem to break anything: the system-installed SWT is used, and there are no SWT libraries installed by the Eclipse ebuild.

> > 	6. Remove from the feature.xml files all the plugins that are for platforms (os, ws, arch) other than the host platform.
> 
> I thought eclipse did not build those plugins in the first place if they
> are not for the relevant host platform?

At least as of Eclipse 3.5, the plugins are built for all platforms, but then only the host platform's plugins are installed by P2.  It's a waste of time and space (in the build directory) to build for the other platforms, so the ebuild removes them.

> > 	7. Remove the doc plugins if the user has the "doc" USE flag disabled.
> > 	8. Remove the source plugins if the user has the "source" USE flag disabled.
> 
> Could be interesting to support as well, though I wonder if the missing
> doc plugins may cause problems when building other eclipse based packages.

As far as I know, there exist no Gentoo ebuilds that depend on dev-util/eclipse-sdk.  If a user has a specific need for the doc plugins, he can simply enable the "doc" USE flag for dev-util/eclipse-sdk.  That's why USE flags exist.  :-)

> > 	[...]
> > 	10. Apply the two patch files that are attached, in addition to the iterators.patch that I sent previously.
> 
> I have no clue what the hamcrest patch does, so I wont comment on that,

The Hamcrest patch solves a problem where the PDT sets up the runtime class path for a plugin incorrectly if the plugin depends on Hamcrest, under the condition that the Hamcrest plugin has been unpacked (as happens on Gentoo in order to utilize the system-installed Hamcrest).

> but the gtk_makefile.patch, I like the idea of it adding support for
> LDFLAGS, but I am not sure I agree with the removal of the -g compiler
> flags (don't know about the -s flag).

Gentoo's policy is to build without debugging information by default.  The user is free to add "-g" to CFLAGS in /etc/make.conf if she wishes.

>   Perhaps we should allow a variable to configure it (defaulting to have
> them present to avoid breaking current setups) - it would also allow our
> users to pass distro specific CFLAGS as well without having to do patches.

The gtk_makefile.patch changes '=' to '+=' in order to allow the user's CFLAGS to be used.

> > 	[...]
> > 	13. Create the launcher script and the desktop menu entry.
> 
> Do you have a template you use for it? Perhaps we can use it in e-b to
> ease the work for people with similar needs.

The launcher script is pretty Gentoo-specific, since Gentoo allows multiple JVMs to be installed simultaneously and has a (unprivileged) user-accessible mechanism for switching among them.

The desktop file is created by the standard ebuild function 'make_desktop_entry'.  I don't know the specifics about how that function works, but here's how the ebuild invokes it:
make_desktop_entry "eclipse-${SLOT}" "Eclipse ${PV}" "${destDir}/icon.xpm" || die

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Back to the top