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
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
--
Ariel Constenla-Haile
La Plata, Argentina
signature.asc
Description: This is a digitally signed message part.
