Rene Engelhard wrote:
Am Donnerstag, 17. August 2006 11:27 schrieb Stephan Bergmann:
- 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.
Right.
- 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
No, exactly that wasn't true either. On Windows *ALSO* the prebuilt one was
taken.
(cws unowinregh also fixed that, but before that even on Windows it was not
built.
See the Issue)
Ok, *that* change is fine with me.
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.
Not true. One mingw32 compiler call :) Of course, there might be no mingw
compiler
available for whatever reason. That's why the "use-the-dll" approach is working
still...
So you agree that "difficult or impossible" *is* true, right?
And the "use-the-dll" approach is now working slightly different (in
that the DLL is no longer checked into CVS, but has to be obtained from
somewhere else), right?
- 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
[...]
Develöoerps who want to deploy stuff using that dll should not use cwses but
released versions. For those, this argument is moot since you then *can* provide
a new unowinreg.dll.
It is not developers who want to "deploy stuff" I am talking about, but
for example developers who want to verify that some CWS will work fine
on a given platform (i.e., want to verify in advance that building on a
given platform will not break once some CWS is integrated).
And if you rebuild it everything works, it just gives problem if you insist of
using the binary,,,
As I explained above, I assume that there are platforms where rebuilding
is simply not posible.
The .dll isn't used except for packging up in a zip, so the build won't fail
either.
This is IMO a bad argument. Each build should result in fully
functional deliverables. You do not know for which reason somebody is
building OOo, so you do not know whether or not it is ok if that build
includes a wrong DLL.
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.)
The problem is that IMHO the rebuilding should be default. It is easily possible
to use the internal one, though. Having it in the cws would make the configure
check more error-prone because it doesn't have a opportunity to check for that
dll anymore.
Sorry, I do not understand what you want to say in this paragraph.
Currently, if the dll is in the tree, it will be used by the build, if not,
you'll get an error if you don't have mingw32. You easily can do that
by either using mingw32 and specifiying --with-mingwin32=... or by coying
the dll (or --disable-odk / --without-java, but that's an other story, and
people who want Java and the ODK obviusly won't use them :) )
What do you mean with "if the dll is in the tree"? The problem that I
see, as I stated before, is the "copying the dll" thing.
-Stephan
Regards,
Rene
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
