Re: [linuxtools-dev] Eclipse Build 0.6.0?

[Niels Thykier <niels@xxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2010-08-11 00:53, Matt Whitlock wrote:
> 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.
> 

It does not matter if you are an official Gentoo Developer or not :)
Some of us are/were not "Official $something" people either and still
pushed changes in to eclipse-build that helped us and others.

>>> 	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.
> 

Possibly because it attempts to embed the native libraries into the jar
files and then extract them later (at install/runtime)

>>> 	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.
> 

How much time/space are you saving here? Does eclipse really have that
many "arch-dependent" plugins that it makes up for the time spent doing
this?

>>> 	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.  :-)
> 

I just noticed it in a couple of my build logs of packages build
depending on eclipse that they were extracting some javadoc and such -
but if you got that covered then that's cool.

>>> 	[...]
>>> 	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).
> 

Assuming it does not break existing setups that do not have the unpacked
version of hamcrest then I am cool with the patch. That being said I
have not tested if this is the case.

>> 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.
> 

True, it would be trivial for both Fedora and Debian to handle this
since maintainers from both distros active contribute to eclipse-build
and participate on this mailing list.
  Particularly with my Debian maintainer hat on, I am cool with it - I
do not have to alter anything since the build by default exports CFLAGS
with -g in it.

However, we may have users/developers not paying so close attention to
e-b that could be surprised by this change.
  Also if we do this, they may even expect us to do/have done the same
about the swt native libraries (a thing I think would be cool - but it
is extra work though).

>>   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.
> 

Totally missed that - my bad.

>>> 	[...]
>>> 	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
> 

Okay, it would seem that you have specialized tools for that already,
guess this would be less of a bonus to add then. :)

~Niels

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREIAAYFAkxoawQACgkQVCqoiq1Ylqw2mACg1wUQ4q7S90adBljN5/X/HI8a
SwwAoNLUlIrOmGTO1ulSxo3RloPY/KF1
=aXMX
-----END PGP SIGNATURE-----