Issue 67661 - Provide unowinreg.dll for SO builds
Summary: Provide unowinreg.dll for SO builds
Status: CLOSED FIXED
Alias: None
Product: Build Tools
Classification: Code
Component: configure (show other issues)
Version: current
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.0.4
Assignee: Martin Hollmichel
QA Contact: issues@tools
URL:
Keywords:
Depends on:
Blocks: 49718
  Show dependency tree
 
Reported: 2006-07-21 14:09 UTC by quetschke
Modified: 2006-08-15 14:16 UTC (History)
4 users (show)

See Also:
Issue Type: TASK
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description quetschke 2006-07-21 14:09:57 UTC 
Removing unowinreg.dll from the source, see issue 49718 - CWS unowinregcross,
propably requires also a change in the SO environment.

Please find a solution for your internal builds.
Comment 1 rene 2006-07-26 17:54:37 UTC 
.
Comment 2 Martin Hollmichel 2006-07-27 15:58:14 UTC 
mh->rt: please have a look onto this.
Comment 3 rt 2006-07-27 16:59:37 UTC 
Hua,  issue 49718 is an interesting read ...
I'll have a look
Comment 4 rt 2006-07-28 14:23:48 UTC 
rene: I meanwhile had a first look at this CWS. Your solution to issue 49718
looks fine to me, allthough I did no test build yet. Just one remark: I
personally would not put that prebuilt dll into modul 'external'. That module
causes trouble from time to time and I'd prefer getting stuff off instead of
into it. Yes, Ause already works on solving this trouble (caused by a SO
internal modul with the same name - he is working on removing that), but I do
not know how long it will take. At least not in 2.0.4 time frame.
For 'moz' we had a similar situation. There the decision was to create a
directory 'download' inside moz module where to put downloaded, prebuilt mozilla
binaries. Wouldn't it be cleaner or at least more obvious to put downloaded
unowinreg.dll somewhere into odk, next to unowinreg sources?
Comment 5 rene 2006-07-29 13:29:15 UTC 
well, we could do (odk/download or odk/source/unowinreg/download or something
like that). I am pretty indifferent with it (as long as it doesn't delay
integration) as I always will rebuild it anyway, but...
Comment 6 rt 2006-08-01 12:58:05 UTC 
rene: Meanwhile I look more into the details.
In principle I still dislike copying a downloaded, prebuilt unowinreg.dll into
module external. Mostly because it is unintuitive: that dll is not external. I
would prefer something like 'odk/source/unowinreg/prebuilt'.
On the other hand, your solution as currently given by issue 49718 has the
advantage that it works and easily can be extended for our SUN internal needs. I
just have to commit 'our' lib somewhere in any SUN internal module and deliver
before 'odk' gets build, the rest is handled by your makefile. Fine. If OOo
configure builds had that dll copied into the 'odk' module but SUN internal ones
had it in a distinct module (because I need it checked in) I would have to
determine in odk makefile what build type we are: configure - take it from odk.
SUN - take it from solver. That would probably require one additional
environment variable, which I try to avoid here. Keep it simple.
So, I change my mind: please let your solution as it is. It's not beautifull,
but working and probably the fastest solution

Ause, if you strongly dislike that solution and have a better proposal, feel
free to open a follow-up issue.
Comment 7 rt 2006-08-01 13:19:52 UTC 
'unowinreg.dll' committed to a SUN internal module. From there it gets delivered
to solver and is available for odk.
Comment 8 rt 2006-08-01 13:24:41 UTC 
Please verify on CWS 'unowinregcross'.
Comment 9 Martin Hollmichel 2006-08-02 14:00:17 UTC 
mark as verified, thanks ruediger.
Comment 10 rt 2006-08-15 14:16:21 UTC 
Seen on master workspace -> closing