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

_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev

Reply via email to