incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [DISCUSS]: new home for pre-built unowinreg.dll
Date Wed, 09 Nov 2011 21:20:03 GMT
2011/11/9 Jürgen Schmidt <jogischmidt@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.

Is this code that almost never changes?  Should we rebuild it for
every official release?

> Juergen
>
>
>
>>
>> Regards,
>> Mathias
>
>

Mime
View raw message