Re: [dev] new build requirement on !Windows - mingw32
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.) -Stephan [...] Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
On 17/08/2006, at 7:06 PM, Jürgen Schmidt wrote: The whole issue came from some extreme views and i like the comment from Volker the extreme view can be correct. Sun takes an extreme position on JCA, and it is also correct that any open source project should be built from sources. jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
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]
Re: [dev] new build requirement on !Windows - mingw32
The work Rene has done with the cross compilation is great, but I think we need to minimize the number of -required- external dependencies. Here is my suggestion for a solution: - Check unowinreg.dll back into the repository and use it by default without recompilation on all platforms. - Include a configure switch that forces recompilation of the DLL. On win32 this uses the standard compiler, on !win32 mingw32. The rule of thumb we used in art pipelines was that if the target file required special software or hardware for generation it should be checked into the repos. Especially if it changed seldom, like the case seems to be here. We need to make our build process easier and adding another application to install or file to download does not further that goal. Kai -- Kai Backman, Software Engineer, [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
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]
Re: [dev] new build requirement on !Windows - mingw32
Kai Backman wrote: The work Rene has done with the cross compilation is great, but I think we need to minimize the number of -required- external dependencies. Here is my suggestion for a solution: - Check unowinreg.dll back into the repository and use it by default without recompilation on all platforms. - Include a configure switch that forces recompilation of the DLL. On win32 this uses the standard compiler, on !win32 mingw32. This suggestion looks fine with me, I would even agree to a setup where recompilation is on by default on those platforms where it is known to work without additional prerequisites (e.g., wntmsci10). (I too think that cross-compilation where possible is a good thing and I too think it is good that Rene integrated the mechanisms that allow to actually do the cross-compilation, in case that was not clear from my previous mails.) -Stephan The rule of thumb we used in art pipelines was that if the target file required special software or hardware for generation it should be checked into the repos. Especially if it changed seldom, like the case seems to be here. We need to make our build process easier and adding another application to install or file to download does not further that goal. Kai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
Kai Backman wrote: The work Rene has done with the cross compilation is great, but I think we need to minimize the number of -required- external dependencies. Here is my suggestion for a solution: - Check unowinreg.dll back into the repository and use it by default without recompilation on all platforms. - Include a configure switch that forces recompilation of the DLL. On win32 this uses the standard compiler, on !win32 mingw32. The rule of thumb we used in art pipelines was that if the target file required special software or hardware for generation it should be checked into the repos. Especially if it changed seldom, like the case seems to be here. We need to make our build process easier and adding another application to install or file to download does not further that goal. +1 that is exactly the solution i have in mind and i have initially assumed that it would be solved in this way and that the cross compilation is only an option for people who can't live with the precompiled dll. Juergen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
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]
Re: [dev] new build requirement on !Windows - mingw32
Hi, Am Donnerstag, 17. August 2006 16:15 schrieb Jürgen Schmidt: Kai Backman wrote: The work Rene has done with the cross compilation is great, but I think we need to minimize the number of -required- external dependencies. Here is my suggestion for a solution: - Check unowinreg.dll back into the repository and use it by default without recompilation on all platforms. - Include a configure switch that forces recompilation of the DLL. On win32 this uses the standard compiler, on !win32 mingw32. [...] +1 that is exactly the solution i have in mind and i have initially assumed that it would be solved in this way and that the cross compilation is only an option for people who can't live with the precompiled dll. No, in the issue you opposed cross-compiling in general and questioned the sense to build it at all. That's not exactly the solution Kai proposed and neither is that how you reacted in the issue. Of course, if you now changed your mind and think that cross-compiling does make sense, good... 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]
Re: [dev] new build requirement on !Windows - mingw32
Rene Engelhard wrote: Hi, Am Donnerstag, 17. August 2006 16:15 schrieb Jürgen Schmidt: Kai Backman wrote: The work Rene has done with the cross compilation is great, but I think we need to minimize the number of -required- external dependencies. Here is my suggestion for a solution: - Check unowinreg.dll back into the repository and use it by default without recompilation on all platforms. - Include a configure switch that forces recompilation of the DLL. On win32 this uses the standard compiler, on !win32 mingw32. [...] +1 that is exactly the solution i have in mind and i have initially assumed that it would be solved in this way and that the cross compilation is only an option for people who can't live with the precompiled dll. No, in the issue you opposed cross-compiling in general and questioned the sense to build it at all. i meant cross compilation in this special case for this library because i am still thinking that it is not necessary but i can understand your opinion. That's not exactly the solution Kai proposed and neither is that how you reacted in the issue. If my comments sound to unfriendly in the issue and even in this thread please forgive me ;-) Of course, if you now changed your mind and think that cross-compiling does make sense, good... i can live with a new configure option to cross compile the library or compile it where possible (wntmsci10) but it shouldn't be the default. I think that the suggested solution by Kai is a good compromise. Do we now all agree to the suggested solution and if yes who will take care of the issue? Juergen Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
Am Dienstag, 8. August 2006 05:48 schrieb Volker Quetschke: Mentioning the possibility of a download of that dll as alternative to installing the mingw package would be nice for the builder that just got bitten by this configure problem. Done in cws configure19. 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]
Re: [dev] new build requirement on !Windows - mingw32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Volker Quetschke wrote: Windows builders are *unaffected*. See $SUBJECT. [...] !Windows [...] /me repeats this to prevent some confusion that Windows builds now require mingw. I didn't say anything else. Actually the configure message should mention the download/copy part. No. (Had that discussion already on IRC...) Regards, Rene -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFE1uyX+FmQsCSK63MRApGnAJ0Tnzg+JtHfjQF1fk0Vga2JNWlucwCfR8+H pnz5/AHlNAAso19xaWBDZRw= =zAe3 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
On Mon, Aug 07, 2006 at 09:32:39AM +0200, Rene Engelhard wrote: Volker Quetschke wrote: Windows builders are *unaffected*. [...] Actually the configure message should mention the download/copy part. No. (Had that discussion already on IRC...) Well, the discussion on IRC basically was you stating: I did not add the URL on purpose and don't want to add it (paraphrased) ciao Christian -- NP: Silverchair - Cemetery - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
Christian Lohmaier wrote: On Mon, Aug 07, 2006 at 09:32:39AM +0200, Rene Engelhard wrote: Volker Quetschke wrote: Windows builders are *unaffected*. [...] Actually the configure message should mention the download/copy part. No. (Had that discussion already on IRC...) Not with me. Where is it documented? Well, the discussion on IRC basically was you stating: I did not add the URL on purpose and don't want to add it (paraphrased) That's a thorough discussion! Because your (debians) opinion is against this all other people that try to build this beast have to suffer. It was your wish (and I support that wish) to get rid of the dll in cvs, but that doesn't mean everyone on any *nix installation has to install some funny mingw cross compiler. Did you check with our friends from *BSD, MacOSX, ... ? Volker -- = http://wiki.services.openoffice.org/wiki/Debug_Build_Problems = PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D signature.asc Description: OpenPGP digital signature
Re: [dev] new build requirement on !Windows - mingw32
Am Montag, 7. August 2006 14:09 schrieb Christian Lohmaier: On Mon, Aug 07, 2006 at 09:32:39AM +0200, Rene Engelhard wrote: Volker Quetschke wrote: Windows builders are *unaffected*. [...] Actually the configure message should mention the download/copy part. No. (Had that discussion already on IRC...) Well, the discussion on IRC basically was you stating: I did not add the URL on purpose and don't want to add it (paraphrased) And I also stated why. 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]
Re: [dev] new build requirement on !Windows - mingw32
Hi Rene, On Mon, Aug 07, 2006 at 02:13:43PM +0200, Rene Engelhard wrote: Am Montag, 7. August 2006 14:09 schrieb Christian Lohmaier: On Mon, Aug 07, 2006 at 09:32:39AM +0200, Rene Engelhard wrote: Volker Quetschke wrote: Windows builders are *unaffected*. [...] Actually the configure message should mention the download/copy part. No. (Had that discussion already on IRC...) Well, the discussion on IRC basically was you stating: I did not add the URL on purpose and don't want to add it (paraphrased) And I also stated why. LOL: the reason being (cited this time): it's a principle to build stuff out-of-source and not ship prebuild things I think I need to upload that log somewhere... ciao Christian -- NP: Silverchair - Cemetery - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
Could someone give pointers to the roots of this whole issue? Why were we checking in a win32 dll into CVS and why do *nix builders have to care? Kai On 8/7/06, Christian Lohmaier [EMAIL PROTECTED] wrote: Hi Rene, On Mon, Aug 07, 2006 at 02:13:43PM +0200, Rene Engelhard wrote: Am Montag, 7. August 2006 14:09 schrieb Christian Lohmaier: On Mon, Aug 07, 2006 at 09:32:39AM +0200, Rene Engelhard wrote: Volker Quetschke wrote: Windows builders are *unaffected*. [...] Actually the configure message should mention the download/copy part. No. (Had that discussion already on IRC...) Well, the discussion on IRC basically was you stating: I did not add the URL on purpose and don't want to add it (paraphrased) And I also stated why. LOL: the reason being (cited this time): it's a principle to build stuff out-of-source and not ship prebuild things I think I need to upload that log somewhere... ciao Christian -- NP: Silverchair - Cemetery - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kai Backman, Software Engineer, [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kai Backman wrote: Could someone give pointers to the roots of this whole issue? Why were we checking in a win32 dll into CVS and why do *nix builders The SDK contains unowinreg.dll, a JNI library needed for deploying Java programs developed with the SDK on Windows. It's needed for accessing Windows' registry. So, till now the file was as binary in CVS, not even on Windows it was built. That was fixed now, it builds now on Windows, and also cross-building it on !Windows using mingw32 was introduced. That said, I still question the need for such a JNI library but anyway Regards, Rene -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFE19VC+FmQsCSK63MRAkWEAJ40/fsQ8AXHj5KQVawawyGUBnOD7wCfUDhJ xRWFR12tlY7rL0dYIdV7sXo= =MIDr -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rene Engelhard wrote: Hi, Volker Quetschke wrote: Well, the discussion on IRC basically was you stating: I did not add the URL on purpose and don't want to add it (paraphrased) That's a thorough discussion! Because your (debians) opinion is against this all other people that try to build this beast have to suffer. That might be true, that's why that external/common mechanism is in place. Anyway, cloph is simplyfing because rebuild from source *is* a principle in the OSS world, not just for Debian.. Although many people apparently don't care that much Err, sorry, text got lost. Add there: And that was what I said. So the default should be to rebuild it and the idea that I didn't add the URL was that I want to save people from using it. Like, see what happen(s/ed) with gpc? There's basegfx' implementation any serious distribution nowadays use, and community builder which doesn't have gpc.c/gpc.h in external/gpc use and it works. But people still use gpc? Why? Because the build instructions tell so and old versions even failed unless you specified --disable-gpc (changed longer ago). Regards, Rene -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFE19cM+FmQsCSK63MRAs2WAJ94LMEN+PuJ0OIMz3cxra/+EsqyIgCdF7H8 2HBbMGCVbyWUhBo5XtDZEc4= =haGn -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Volker Quetschke wrote: Rene Engelhard wrote: Hi, with integration of cws unowinregcross (and therefore in m181) we have a new build requirement: mingw32. See issue 49178. This is not completely true, since m181 and only for non-Windows targets there is the possibility to either install mingw32 or to copy unowinreg.dll to external/unowinreg/ (You can get it here: http://tools.openoffice.org/unowinreg_prebuild/680/). Windows builders are *unaffected*. /me repeats this to prevent some confusion that Windows builds now require mingw. Actually the configure message should mention the download/copy part. So you want me to error out in the unowinreg.dll not found case instead of warning and continuing to try to use mingw32? Or just mentioning them in the warning? Regards, Rene -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE1/hr+FmQsCSK63MRAitWAJ4kjf69ErUcJRI2Imi+u7xH28ju3QCfXU58 9CD1mAEQHry1Wndo/JZNxlo= =qhPp -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
Moin! Rene Engelhard wrote: Rene Engelhard wrote: Hi, Volker Quetschke wrote: Well, the discussion on IRC basically was you stating: I did not add the URL on purpose and don't want to add it (paraphrased) That's a thorough discussion! Because your (debians) opinion is against this all other people that try to build this beast have to suffer. That might be true, that's why that external/common mechanism is in place. Anyway, cloph is simplyfing because rebuild from source *is* a principle in the OSS world, not just for Debian.. Although many people apparently don't care that much Thank you. Err, sorry, text got lost. Add there: And that was what I said. So the default should be to rebuild it and the idea that I didn't add the URL was that I want to save people from using it. Alright, my opinion pales in front of the OSS gods, but we are talking about developing a nice project here. I don't want to add extra time to the build by rebuilding external dependencies. So why do I have to add the switches to disable the rebuilding just so that distros that don't have to provide the enable switches? Like, see what happen(s/ed) with gpc? There's basegfx' implementation any serious distribution nowadays use, and community builder which doesn't have gpc.c/gpc.h in external/gpc use and it works. But people still use gpc? Why? Because the build instructions tell so and old versions even failed unless you specified --disable-gpc (changed longer ago). Cool, ever thought about fixing the build instructions when changing configure? Breaking stuff for the greater OSS good is always easy, but _we_ are trying to maintain a cross-platform product here and have to show some tolerance. Volker - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D signature.asc Description: OpenPGP digital signature
Re: [dev] new build requirement on !Windows - mingw32
Rene Engelhard wrote: Volker Quetschke wrote: Rene Engelhard wrote: Hi, with integration of cws unowinregcross (and therefore in m181) we have a new build requirement: mingw32. See issue 49178. This is not completely true, since m181 and only for non-Windows targets there is the possibility to either install mingw32 or to copy unowinreg.dll to external/unowinreg/ (You can get it here: http://tools.openoffice.org/unowinreg_prebuild/680/). Windows builders are *unaffected*. /me repeats this to prevent some confusion that Windows builds now require mingw. Actually the configure message should mention the download/copy part. So you want me to error out in the unowinreg.dll not found case instead of warning and continuing to try to use mingw32? Or just mentioning them in the warning? Mentioning the possibility of a download of that dll as alternative to installing the mingw package would be nice for the builder that just got bitten by this configure problem. Volker - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- = http://wiki.services.openoffice.org/wiki/Debug_Build_Problems = PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D signature.asc Description: OpenPGP digital signature
Re: [dev] new build requirement on !Windows - mingw32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rene Engelhard wrote: with integration of cws unowinregcross (and therefore in m181) we have a new build requirement: mingw32. See issue 49178. ^ 49718 Regards, Rene -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE1kHy+FmQsCSK63MRAh+JAJ96vVf+VcGlCcT/ghG4buVoMi6isACfWIlV dPYAI0DLfoWz9737diUAX60= =KojF -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
Rene Engelhard wrote: Hi, with integration of cws unowinregcross (and therefore in m181) we have a new build requirement: mingw32. See issue 49178. This is not completely true, since m181 and only for non-Windows targets there is the possibility to either install mingw32 or to copy unowinreg.dll to external/unowinreg/ (You can get it here: http://tools.openoffice.org/unowinreg_prebuild/680/). Windows builders are *unaffected*. /me repeats this to prevent some confusion that Windows builds now require mingw. Actually the configure message should mention the download/copy part. Volker It is used for building unowinreg.dll (because using random binaries out of CVS is bad(tm)). So you need to install mingw32; IIRC mingw32 has binaries; if not, you also can take the Debian debs and alienize them: http://packages.debian.org/mingw32 http://packages.debian.org/mingw32-runtime http://packages.debian.org/mingw32-binutils You need to add --with-mingwin=mingw32-g++-binary-name to your configure flags (e.g. --with-mingwin=i586-mingw32msvc-g++). Regards, Rene -- = http://wiki.services.openoffice.org/wiki/Debug_Build_Problems = PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D signature.asc Description: OpenPGP digital signature
