On 11/9/11 10:20 PM, Rob Weir wrote:
2011/11/9 Jürgen Schmidt<jogischm...@googlemail.com>:
On 11/5/11 1:30 PM, Mathias Bauer wrote:
Am 01.11.2011 14:15, schrieb Jürgen Schmidt:
Hi,
for all unix builds it is possible to use a pre-built unowinreg.dll that
is used in the SDK for Java client applications.
Background:
This dll contains some glue code that helps to find a default office
installation on windows. This is used to bootstrap an UNO environment
and establish a remote connection to an existing or new office instance
from the Java client application that triggers this code.
If is possible to cross compile this dll with mingw in some way but not
really necessary. It was always possible to download a pre-built version
and include it in the SDK on all plattforms expecting Windows where it
is built always.
I would suggest that we store this pre-built dll somewhere to ensure
that this mechanism can be used or will work in the future as well.
The URL to download the pre-built version is
http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll
The code is part of the odk module and is quite simple. Means it can be
always checked what's in the dll. We can apply a md5 checksum to ensure
that no manipulated dll is downloaded.
Any ideas where we can store this dll in the future?
In the build the unowinreg.dll is expected to be in external/unowinreg.
Usually the developer needs to copy it there. We could just check it in
there in case we wanted to stick with the binary.
i think it is not allowed to check in binaries in the source tree, at least
pre-built ones. I would be happy with this solution because it was the
solution we had at the beginning ;-)
The binary is Apache 2.0 license? If so, I think it is OK. At least
no policy problem. It is odd from an engineering standpoint. But I
see the argument: we are building a Java library that calls into a
native method via a platform-specific native library. If we want to
be able to build that SDK on Linux, then we need to be able to package
the Windows DLL. This is because even if we build on Linux, the user
of the SDK might run their code on any platform, including Windows.
So we need to be able to package Windows native code on a Linux-built
SDK.
Checking in the Windows DLL seems to be the easiest solution. Maybe
put a clear README file in that directory so other developers know
what is going on and how to rebuild it.
ok, if nobody else has any concerns i will move forward with this
approach and check it in in the odk module and change everything ...
Is this code that almost never changes? Should we rebuild it for
every official release?
well we build it always under Windows to ensure that it is still
compilable. Changes are rather seldom.
Juergen
