-----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-----
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
