Thanks Caolan for explaining that to me.
I need the platform descriptions for the Extension Manager. Currently
one can install an extension on any platform, no matter for what
platform the extension is intended. In the future the Extension Manager
should refuse to install an extension when it cannot work on the user's
system.
To achieve this, the extension contains a platform token and the
Extension Manager checks if this token represents the current platform.
As for the s390x and ppc64 there should be a definition for _ARCH in
macro.hxx as well as for the different ABIs. This is probably the
easiest way.
Will there still be future builds for the old ABI? If not then we
would not need it (at least the Extension Manager). Then we could just
use mips and arm.
Assuming that the old ABIs will be used, please go ahead with adding the
new definitions for _ARCH. Put me on cc so I can do the follow up
changes to the Extension Manager.
Anyway, I would not wait until your CWS is integrated, because then I'm
afraid that my CWS will not be accepted for OOo 3.0 anymore. But we can
add additional platforms later on.
>> However, currently we could add
>> linux_arm
>> linux_mips
>
> btw, where do these get added ? Are they being added e.g. to some sort
> of "these are the extensions available for your platform" section of a
> website ?
Currently it is only planned to have the Extension Manager check the
platform during installation. The openoffice extension repository web
site could, of course, make use of this information, but currently there
is nothing planned. When my CWS will be integrated, I will communicate
this to the people who develop the web site, so they can decide what to
do with it.
Joachim
Caolan McNamara wrote:
On Mon, 2008-03-31 at 11:40 +0200, Joachim Lingner wrote:
This platform cannot be obtained currently using the bootstrap API, for
example:
OUString os( RTL_CONSTASCII_USTRINGPARAM("$_OS") );
::rtl::Bootstrap::expandMacros( os );
We use $_OS and $_ARCH to obtain platform information.
Possible values
are defined in rtl/source/macro.hxx. ppc64 is currently not support.
True, ppc64 is detected in that list as simply "ppc" with no
distinction from ppc32, which is the same situation as the 32bit s390
vs 64bit s390x. And the two different ABIs possibilities for arm are
both simply recorded as ARM and also both the endian variants for MIPS
are not distinguished between in macro.hxx
It was never previously a problem from the point of view that it wasn't
necessary to distinguish between them in sal to successful build OOo.
With the other sizeof(long) stuff taking care of the 32bit/64bit
differences and build-time logic selecting which uno bridge to build.
Are s390x arm_eabi, arm_oabi, mips_el, mips_eb names for particular CPU
types? If so, then the bootstrap API should be extended accordingly.
Well the eabi vs oabi are two different ABIs that are possible for ARM,
with the eabi being the new one. The CPU is the same, but most distros
basically treat them as two different CPUS. If it is important then I
can clean up the macros.hxx to enumerate explicitly and distinguish
binary incompatible platforms from each other so there's a unique
THIS_ARCH for each.
However, currently we could add
linux_arm
linux_mips
btw, where do these get added ? Are they being added e.g. to some sort
of "these are the extensions available for your platform" section of a
website ?
C.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
