Hi Andrew,
Last week I started looking into making our eclipse packages mulitlib
compatible to solve bug # 207016 and I thought I'd write up a little
status report of what I found.
Here are the issues we need sort out:
1) Ensure the src zips are the same for all arches
2) Put the native fragments in %{_libdir} - the swt classes need to go
there too because they use 32-bit or 64-bit references depending on
the arch
3) Ensure that configuration will work when the user has different
32-bit features and 64-bit features installed (e.g. 32-bit platform
and jdt with 64-bit platform, jdt and pde)
Solutions:
1) ensuring the src zips are the same for all arches
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Repack all the zips at the end of the build similar to how the brp
script repacks all jars
OR
- Make the non-arch dependent packages noarch so that the src zips will
come from same package on all arches. IIRC the kernel has a hack to
do this for its doc package
2) Putting native code in %{_libdir}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This site explains how to configure eclipse to put features and plugins
in separate directories:
http://www-128.ibm.com/developerworks/opensource/library/os-ecl-manage/
The only method that works for SWT is the one that requires the user to
add an extension location in the configuration manager. Obviously this
is not useful for a build, but we may be able to take the configuration
it adds to configuration/org.eclipse.update/platform.xml and insert it
in the build.
With this we will need to have
configuration/org.eclipse.update/platform.xml and we cannot remove like
we have been planning. So we can either use the rebuild features script
again or we can run the file initializer with an empty configuration
every time an eclipse package is installed. For the file initializer
solution I'm not sure if this will preserve section of platform.xml that
specifies the separate location of the native fragments. I still need to
test this out.
As far as using the rebuild features script again, we have already seen
that using it is not really maintainable because it's difficult to know
what format the platform.xml file needs to be in. Also, we shouldn't
create procedures that require us to maintain code outside of the
upstream code. We already spend most of our time packaging stuff and
don't have time to respond to real bug reports in a timely manner.
Adding this again would just tie us up even more and would be a bad
decision IMHO. But if there's no other method that will work, then we
have no choice.
3) Working with different 32 and 64 bit features
================================================
We will need to drop the sed logic that changes configuration/config.ini
and always run with eclipse.product=org.eclipse.platfrom.ide or
eclipse.product=org.eclipse.sdk.ide because both the 64-bit packages and
the 32-bit packages will change that config entry. If the two sets of
packages get out of sync, this will be set incorrectly.
The solutions for problem 2 might might also cause problems here if the
packages get out of sync. Here's an example:
If a user has both the 32-bit eclipse-sdk and the 64-bit eclipse-sdk
package installed and then removes the 64-bit eclipse-sdk and
eclipse-pde, the 32-bit eclispe-sdk and 32-bit eclipse-pde will not be
removed and the pre-configuration will not be set correctly because the
packages share configuration directory. I think this would be a problem
for both the rebuild features script and the file initializer solution.
I don't really have a solution for this problem. Andrew, do you have any
thoughts? If we could specify a different configuration directory, we
would be able to get around this, but I haven't run across any way to do
this yet.
Ok, that's all I have for now. I'll continue working on this.
Ben
--
fedora-devel-java-list mailing list
fedora-devel-java-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
