On 05/25/10 15:41, Ariel Constenla-Haile wrote:
Hello Patrick,
On Tuesday 25 May 2010, 05:09, Patrick Bernard wrote:
I'm developing an extension in C++ on Ubuntu with the OOo sdk, make and g++
as build environment.
so you are using the OOo SDK build environment, aren't you?
The extension will be available for several
platforms (Windows, Mac OS X, Ubuntu), but not at the same time. There
will be a version of the extension for each platform. As you can see in
DevGuide/Extensions/Extension_Identifiers, the identifier used for the
extension must be unique, even among extensions that are logically the same
but support different platforms. Besides, the file description.xml must
contain a platform element with the platform token.
this is true if you take the approach of creating one OXT file for each
platform/architecture, so you must have
a) MyExtension_Linux_x86.oxt
b) MyExtension_Linux_x86_64.oxt
c) ...
all with the same extension identifier in description.xml but
The identifier must be different! Otherwise, using the online update you
could download and install an extension, which is not supported on your
platform. The extension manager uses only the identifier and version to
determine if there is an update available.
--Joachim
a) <platform value="linux_x86"/>
b) <platform value="linux_x86_64"/>
c) ...
or you can take the approach of having only one OXT file, without specifying
the platform in description.xml; placing inside the extension's root dir. a
directory for every plat./arch. with the respective library
OXT_ROOT_DIR/Windows/mylib.uno.dll
OXT_ROOT_DIR/Linux_x86/libmylib.uno.so
OXT_ROOT_DIR/Linux_x86_64/libmylib.uno.so
and leave platform/arch. handling in the manifest only:
OXT_ROOT_DIR//META-INF/manifest.xml
<manifest:file-entry manifest:media-type="application/vnd.sun.star.uno-
component;type=native;platform=Linux_x86"
manifest:full-path="Linux_x86/libmylib.uno.so"/>
<manifest:file-entry manifest:media-type="application/vnd.sun.star.uno-
component;type=native;platform=Linux_x86_64"
manifest:full-path="Linux_x86_64/libmylib.uno.so"/>
<manifest:file-entry manifest:media-type="application/vnd.sun.star.uno-
component;type=native;platform=Windows"
manifest:full-path="Windows/mylib.uno.dll"/>
I guess this approach will have the drawback that if you do not provide a
component library for the respective platform/arch. where the extension is
installed, the user gets the extension installed anyway without any warning.
I thought that this
token could be obtained automatically from the sdk, to avoid setting it
manually.
AFAIK it is not possible.
Both $(PLATFORM) and $(PROCTYPE) are there to help set, in some cases,
$(UNOPKG_PLATFORM), which is used for the name of the folder containing the
UNO component library, and for setting the platform in the manifest' media-
type; see for example
http://svn.services.openoffice.org/opengrok/xref/DEV300_m78/odk/examples/cpp/complextoolbarcontrols/Makefile#121
If it is not possible, I would like to know why.
I guess Jürgen never had in mind someone will actually use the OOo SDK build
environment to build a C++ extension with all the latest features provided now
by OOo Extension framework.
You can submit an issue asking for this enhancement.
In the meantime, using the OOo SDK build environ. you can find a solution
adding some custom include to your makefile (it easier to maintain than adding
it to your main makefile) right after including OOo SDK's ones, something like:
include set_env/project_platform_settings.mk
where project_platform_settings.mk has some conditional definition (using the
variables already set by the SDK) of a variable, let's say,
DESCRIPTION_PLATFORM, that you use to generate the correct platform in the
description.xml:
@echo $(SQM) $(SQM)$(OSEP)platform
value="$(QM)$(DESCRIPTION_PLATFORM)$(QM)"/$(CSEP) >> $@
(this assumes you are using the approach of echoing the description.xml, as
the SDK makefiles do with the manifest.xml).
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org