Stephan Bergmann wrote:
Rene Engelhard wrote:
Hi,
with integration of cws unowinregcross (and therefore in m181) we have a
new build requirement: mingw32. See issue 49178.
That should read "See issue 49718", I assume.
It is used for building unowinreg.dll (because using random binaries out
of CVS is bad(tm)).
Sorry for stepping into this so late. As far as I understand, the
situation is as follows:
- We have some OOo source files in odk/source/unowinreg/win/ from which
a Windows DLL is built, and that Windows DLL is needed on all platforms,
not just Windows.
- On SRC680m180 and earlier, the DLL resulting from the sources is
checked into CVS as odk/bin/win/unowinreg.dll. On Windows, the DLL is
built from sources, on all other platforms, the checked-in version is
used. If anybody changes the sources in odk/source/unowinreg/win/, that
person is required to also check in a new odk/bin/win/unowinreg.dll
(i.e., do a build on Windows to obtain the new DLL and then check it
in). The rationale for the checked-in DLL is that it is difficult or
impossible to build the DLL on platforms other than Windows.
- Since SRC680m181, the DLL resulting from the sources is no longer
checked into CVS. Rather, as a new prerequisite you either need to have
the necessary tools available to build it from the sources (i.e., a
cross compiler, which might not be available for every platform), or you
need to copy the DLL from somewhere. If anybody changes the sources in
odk/source/unowinreg/win/, that person is required to make the new
version of the DLL globally available somewhere (but not replacing the
globally available old version of the DLL, as that might still be needed
by people building an older version of OOo) and inform everybody that
the prerequisite of copying the DLL from somewhere A has changed to
copying it from somewhere B. This step is further complicated by our
child workspace mechanism: The changes to odk/source/unowinreg/win/
will happen on some CWS first. So that anybody can build that CWS, a
CWS-specific version of the DLL needs to be made available globally, and
everybody needs to be informed that when building the CWS, the
prerequisite of copying the DLL has changed. Then, the CWS will be
integrated into some MWS, and before the MWS is announced as available,
an MWS-built version of the DLL (which might differ from the
CWS-specific version, e.g., if multiple CWS that made changes to
odk/source/unowinreg/win/ are integrated simultaneously) needs to be
made available globally, and everybody needs to be informed about the
changed prerequisite (and who does do that, the person that did the
changes to odk/source/unowinreg/win/ or the person that announces the
availability of the new MWS?).
Honestly, the old way looks much less error prone, as it leverages
established mechanisms (CVS) to avoid some of the pitfalls. It is of
course a laudable approach to build as much as possible from sources.
However, that approach apparently has its limits, and you have to be
careful not to stretch it too far.
Given these reasons, I strongly vote for undoing the changes introduced
in SRC680m181.
(The changes on SRC680m181 might also allow to---optionally---build the
DLL from sources on more platforms than was possible before. If that is
the case, I think that is a good move which should of course not be
undone. It is just the moving of the precompiled DLL from CVS to
somewhere else that I find highly problematic.)
thank you Stephan for the precise summary here. I agree in all points.
Juergen
-Stephan
[...]
Regards,
Rene
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
