Am Donnerstag, 17. August 2006 15:51 schrieb Stephan Bergmann: > >> 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?
No, at least not generally. It might be true for some platform, though. > > 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 why should they need to care about unowinreg.dll when they didn't change it? Of course, if they did change it in the cws they need to rebuild and test it, but that's normal QA... > > 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. What currently is done is: - check whether the dll is there - if *not* rebuild it - fail when mingw32 isn't there. If the dll is in the tree again the check whether the dll is there always would be true (and it needs to be adapted anyway..). The configure check would need to be rewritten to *always* take the dll (because it's there) and only optionally cross-compile it. (See Kaibs mail. I don't really like that, though, but if the majority wants this.... But as oyou wrote in your other post, you do agree with cross-compiling it...) > > 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. Yes, but you *could* send announce mails for big changes in that dll. YOu already have that feature mail mechanism. There already is the prodecure to announce new build reqs on this list (as I did with my initial post) Regards, Rene -- René Engelhard -- Debian GNU/Linux Developer -- Debian OOo Maintainer-Team http://www.debian.org | http://people.debian.org/~rene/ | [EMAIL PROTECTED] http://openoffice.debian.net | debian-openoffice@lists.debian.org GPG: 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]
