openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <>
Subject Re: [DISCUSS]: new home for pre-built unowinreg.dll
Date Thu, 10 Nov 2011 10:39:58 GMT
On 11/9/11 10:20 PM, Rob Weir wrote:
> 2011/11/9 Jürgen Schmidt<>:
>> 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
>>>> 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.


View raw message