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) > 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... > - 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. And if you rebuild it everything works, it just gives problem if you insist of using the binary,,, The .dll isn't used except for packging up in a zip, so the build won't fail either. > 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. 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 :) ) Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
