[tools-dev] Build Bots error in WITH_LANG variable
Hi, the CWS gnumake3 failed in all build bots. The reason is that - according to the logs - the variable "WITH_LANG" is set to ' '. See: http://termite.services.openoffice.org/buildbot/builders/Windows-2003/builds/1994/steps/Compile/logs/stdio (in case it's still there) Does anybody know why? IMHO it should be empty or unset. I don't think that it makes sense to check WITH_LANG in makefiles for being empty or a space. For the time being I will do it to get the CWS approved. But IMHO we should fix the build bots. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Error instsetoo_native: codes.txt not found
On 06/24/2010 02:27 PM, Davide Dozza wrote: Davide Dozza ha scritto: Mathias Bauer ha scritto: [...] That indicates that your frmmi.dll is either not there or misses some prerequisites. You can find out more using the dependency walker tool that you can download from the Internet (http://www.dependencywalker.com). Please go do the solver/bin folder and call "$(depends) frmmi.dll". "$(depends)" is the path to your depends.exe. You should see which dll is missing or where symbols in a dll are missing. Depends reports that frmmi.dll was corrupted. I suppose I've to rebuild the solver. Uhm... I reply myself. I've rebuilded forms module which is the oring of frmmi.dll After the command deliver inside forms module, should I rebuild something? AFAIK there is no other library that depends on the forms library, so I think that you don't need to rebuild something else. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Error instsetoo_native: codes.txt not found
Hi Davide, On 24.06.2010 10:09, Davide Dozza wrote: In the log file I've found: register component 'file:///C:/DEV300_m81/solver/300/wntmsci12.pro/bin/frmmi.dll ' in registry 'C:/cygwin/tmp/ooopackaging/i_4401277366115/wntmsci12.pro/OpenOffi ce/archive/gid_Starregistry_Services_Rdb_servicesrdb/en-US_inprogress_1/services .rdb' failed! error (CannotRegisterImplementationException): loading component library failed: file:///C:/DEV300_m81/solver/300/wntmsci12.pro/bin/frmmi.dll Here you can find the complete log file. http://wikisend.com/download/528490/log_DEV300_en-US.log That indicates that your frmmi.dll is either not there or misses some prerequisites. You can find out more using the dependency walker tool that you can download from the Internet (http://www.dependencywalker.com). Please go do the solver/bin folder and call "$(depends) frmmi.dll". "$(depends)" is the path to your depends.exe. You should see which dll is missing or where symbols in a dll are missing. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] EIS CWS AllowedRelease/AllowedTaskTargets Problems
On 22.06.2010 14:49, Bernd Eilers wrote: Mathias Bauer wrote: Hi, Hi, the "right solution" would be to remove the check. A target milestone is a hint when a particular should be fixed or is planned to be fixed. The same is true for a CWS. If a developers decided to fix an issue earlier or finish a CWS earlier, why should that be marked as "failed"? Because the data of the issue doesn´t match the data of the CWS and we have an inconsistent state in the tools that document what we are doing. Where is the point of not wanting to also change the issue data if the decision when to fix the issue did change. Why do you want to refuse to document that by changing the issue data. The "failed" status in this case is just a "hint" to the developer that there are issues on his CWS which either need to be fixed on another CWS which is based on another codeline or which need to be adjusted to be fixed on another target which might eventually also need an agreement about that with other stakeholders involved. That's exactly what Stephan said: bureaucratic humbug. Well I know we do have some members in an implement_as_you_want_when_you_want_and_dont_care_about_qa-needs_roadmaps_or_documentation camp but I didn´t really expect you two to be in there ;-) That's complete nonsense. Setting a target to an issue or CWS can be done short before or even after a CWS is integrated. If you ever had to change the targets of issues or CWS just because you had set them to the "allowed" target but then - when the CWS did not make it into the release - had to change it again, you might understand why I think that is bureaucratic humbug. The target release of an issue or CWS *before* it gets integrated is unrelated to what is documented or even to what exactly ends in the release. In a "train model" you never know the time of arrival exactly before the train really arrives. So a "target release" is just a declaration of what is aimed for, nothing else. Why else are we retargetting so much issues each and every release? Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Error instsetoo_native: codes.txt not found
Hi Davide, On 19.06.2010 13:43, Davide Dozza wrote: I'm still trzing to compile DEV300_m82 on WinXP and now I've found this problem: Entering /cygdrive/c/DEV300_82/instsetoo_native/util dmake: makefile.mk: line 211: Warning: -- Prior to dmake 4.5 only one %-target per target-definition worked reliably. Check your makefiles. C:/cygwin/bin/perl -w C:/DEV300_82/solenv/bin/make_installer.pl -f ../util/openo ffice.lst -l en-US -p OpenOffice -u ../wntmsci12.pro -buildid 9510 -msitemplate ../wntmsci12.pro/misc/openoffice/msi_templates -msilanguage ../wntmsci12.pro/mis c/win_ulffiles -format archive Subroutine installer::epmfile::getcwd redefined at C:/DEV300_82/solenv/bin/modul es/installer/epmfile.pm line 43 ... checking environment variables ... ... cleaning the output tree ... ... removing directory C:/cygwin/tmp/ooopackaging/i_25721276937464 ... ** ERROR: ERROR: Cannot find file C:/DEV300_82/instsetoo_native/wntmsci12.pro/misc/ openoffice/msi_templates/codes.txt in function: check_file ** ** ERROR: Saved logfile: logfile.log ** Sat Jun 19 10:51:06 2010 (00:04 min.) dmake: Error code 255, while making 'openoffice_en-US.archive' Davide this is a known problem and I asked the developer to fix it, but unfortunately he didn't do that until now. It seems that I should ask again. You can workaround the problem by setting "BUILD_SPECIAL" to TRUE before calling "build" in instsetoo_native. Regards, Mathias - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] EIS CWS AllowedRelease/AllowedTaskTargets Problems
Hi, the "right solution" would be to remove the check. A target milestone is a hint when a particular should be fixed or is planned to be fixed. The same is true for a CWS. If a developers decided to fix an issue earlier or finish a CWS earlier, why should that be marked as "failed"? That's exactly what Stephan said: bureaucratic humbug. The check for "all tasks fixed" is another story. It makes sense to check that before a CWS is waiting for QA approval. Regards, Mathias On 21.06.2010 12:00, Bernd Eilers wrote: Hi there! I think the real root cause is that the definitions of what can be done on which codeline is currently often not done early enough. As soon as a new target is being created for the bugtracking system the corresponding rules should be configured in EIS also. If that would be the case we wouldn´t have any annoyance either. If that doesn´t work somebody just has to complain to the group of people which have been assigned to do these administrative tasks and that is "program management". Doing such test only when the cws is being set to "ready for QA" just because some developers don´t like to see the color red is IMHO not the right solution. On the contrary I would argue that maybe even setting the CWS to "ready for QA" shouldn´t be allowed at all if there are tasks with the wrong target. Kind regards, Bernd Eilers Mathias Bauer wrote: Hi, ACK. If we think that we need that bullshit, the status should at least not be set to "failed" before the CWS is ready for QA. That still would be bureaucratic humbug (because both fields are that per se), but at least some humbug that is less annoying. Regards, Mathias On 18.06.2010 12:06, Stephan Bergmann wrote: What a heap of bureaucratic humbug. -Stephan On 06/18/10 11:43, Bernd Eilers wrote: Hi Stephan! There is no "error" in EIS, EIS behaves just as it was instructed to do. If you click on the "Details" link you will find the following information: - The release of this ChildWorkspace is OOo 3.4 . The release of the CWS is invalid. The allowed Releases for the MasterWorkspace of this CWS are: OOo 3.1 , OOo 3.2 , OOo 3.1.1 , OOo 3.3 , OOo 3.2.1 The List of allowed Releases for MasterWorkspaces is being maintained by program management. - This all basically means that if you think OOo 3.4 should be in the list for that MasterWorkspace but isn´t ask your friendly program manager next door to add it. Kind regards, Bernd Eilers Stephan Bergmann wrote: For a CWS based on DEV300 with release set to OOo 3.4 and all associated tasks having target OOo 3.4, AllowedRelease and AllowedTaskTargets erroneously are both set to failed (e.g., see <http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=9434&OpenOnly=false&Section=All>). -Stephan - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] EIS CWS AllowedRelease/AllowedTaskTargets Problems
Hi, ACK. If we think that we need that bullshit, the status should at least not be set to "failed" before the CWS is ready for QA. That still would be bureaucratic humbug (because both fields are that per se), but at least some humbug that is less annoying. Regards, Mathias On 18.06.2010 12:06, Stephan Bergmann wrote: What a heap of bureaucratic humbug. -Stephan On 06/18/10 11:43, Bernd Eilers wrote: Hi Stephan! There is no "error" in EIS, EIS behaves just as it was instructed to do. If you click on the "Details" link you will find the following information: - The release of this ChildWorkspace is OOo 3.4 . The release of the CWS is invalid. The allowed Releases for the MasterWorkspace of this CWS are: OOo 3.1 , OOo 3.2 , OOo 3.1.1 , OOo 3.3 , OOo 3.2.1 The List of allowed Releases for MasterWorkspaces is being maintained by program management. - This all basically means that if you think OOo 3.4 should be in the list for that MasterWorkspace but isn´t ask your friendly program manager next door to add it. Kind regards, Bernd Eilers Stephan Bergmann wrote: For a CWS based on DEV300 with release set to OOo 3.4 and all associated tasks having target OOo 3.4, AllowedRelease and AllowedTaskTargets erroneously are both set to failed (e.g., see <http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=9434&OpenOnly=false&Section=All>). -Stephan - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] New build system
Hi, I've just posted a status update for our build environment effort to the global dev list. I think this is a more appropriate list for that, as I want to reach more people than usually hang around on this list. ;-) So please follow up in the global dev list. Best regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Smoketest fails on RedFlag build bot for CWS nspluginglobal
Frank Schoenheit, Sun Microsystems Germany wrote: > Hi Mathias, > >> So my assumption is that executing the smoke test is broken on that >> machine in general. Can someone confirm this? > > http://tools.openoffice.org/servlets/ReadMsg?list=tinderbox&msgNo=350 > > Ciao > Frank > > - > To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org > For additional commands, e-mail: dev-h...@tools.openoffice.org > Thanks! Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] Smoketest fails on RedFlag build bot for CWS nspluginglobal
Hi, for an obscure reason the RedFlag build can't execute the smoke test for the CWS nspluginglobal, it seems that it already fails in the installation step. OTOH in this CWS nothing has been changed that could be relevant either for the packaging or the installation process. So my assumption is that executing the smoke test is broken on that machine in general. Can someone confirm this? And if that is true, can we disable the smoke test on that machine until it is fixed? Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: [dev-educ] Wiki Cleanup: Mission Accomplished (Mostly)
eric wrote:
> Why yet another war against Education Project ?
You shouldn't jump to conclusions. Björn has sent mails to many mailing
lists, not only yours. First he asks for using categories at all for
reasons that have been discussed and explained on the dev list. Please
just use *any* category ("education" would fit the bill) so that we can
identify orphaned and obsolete pages easier.
His mail also is just a friendly hint that using more specific
categories could help interested readers to find what they are looking
for. It's completely up to you if you want to follow that. If you are
fine with using "education" as the category, no problem.
> If you remove the IRC meeting, I'll stop immediately to contribute to
> the OpenOffice.org Wiki, and I'll publically explain what happened.
I recommend to cool down. You got a friendly hint and answered it with a
blackmailing attempt. Not something that lets you look good in the public.
Regards,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamfor...@gmx.de".
I use it for the OOo lists and only rarely read other mails sent to it.
-
To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org
For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] New Build System Requirements
Thorsten Behrens wrote: > Mathias Bauer wrote: >> I just wanted to point out that you seem to underestimate the value >> of a less diverse build system. Most probably because you don't >> have to maintain it. ;-) >> > Quite the contrary. I have to personally setup all the win32 build > prerequisites on each and every box or vm I want to build OOo with - > and it's a royal PITA. That's why I maintain that cygwin is not the > problem. But as you noted elsewhere, we'll likely need to keep it no > matter what (for the while), so I guess this point is settled. ;) Yes, and moreover, I think that most of this side step discussion was caused by a misunderstanding. Getting a leaner build system than we have now is important (IMHO), but of course it is not the most important point in a way that the "leanest" new system automatically would be the best. It might make the difference though in case all else is equal (or at least similar). If that's what you call "a runner-up goal", I agree with you. Nevertheless it's good to track that on our page as this might be something we have to consider. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] New Build System Requirements
Thorsten Behrens wrote: > The story on win32 (and other, not-so-standard platforms I believe > you alluded to) is totally different, of course, but you won't fix > that by prohibiting sed & awk - fixing the root cause here means > performing cross-compilation for those platforms. > > (you need to build/debug natively on those platforms? sure, but > binning e.g. cygwin from the impressive list of ~14 build > prerequisites > http://wiki.services.openoffice.org/wiki/Development/OpenOffice.org_Building_Guide/Building_on_Windows#software_requirements > means getting rid of the _least problematic_ one - trivial to install, > easy to update, free, built-in package management etc. - shouldn't we > rather eliminate the real deal-breakers there first?) You are jumping to conclusions. I didn't talk about a particular dependency I wanted to avoid. I just wanted to point out that you seem to underestimate the value of a less diverse build system. Most probably because you don't have to maintain it. ;-) Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] New Build System Requirements
Stephan Bergmann wrote: > On 02/03/10 15:38, Mathias Bauer wrote: >> I tend to agree that - whatever we will do - we probably won't get rid >> of cygwin. Where we have to get rid of it is the building of the >> "normal" modules. >> >> As an example, if a developer is going to work on "sw", he might want to >> build sw and all c++ libraries it depends on (well, without the external >> ones). Being able to do that in Visual Studio would be a tremendeous >> achievement. But using Visual Studio as a "launcher" for cygwin shells >> is probably not what we want here. So the build of "normal" C++ >> libraries should run inside VS completely. > > Not sure what your scenario is where the developer "might want to build > [just] sw and all c++ libraries it depends on," but doing all of that > strictly inside VS would not work if any of those C++ libraries in turn > depended on something not buildable strictly inside VS (e.g., thinking > of things like flex/bison/idlc/cppumaker/whatever invocations). Well, "all" was perhaps too much. I was aiming on what you usually work with. A lot of common build scenarios require nothing special, just the "usual suspects". Many modules could be build with Visual Studio. That's nothing for a complete build, but very useful for the daily work of the developers. That would definitely be a benefit. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] New Build System Requirements
Mathias Bauer wrote: > Jussi Pakkanen wrote: > >> Another point is "However, there are many cases where the current >> build process depends on a large set of external tools like bash, awk, >> findutils, coreutils." Does the actual building require these or is it >> more of a case of "need these, because dmake/build.pl needs these"? In >> my OOo CMake experiment I built idlc, generated urd, Java etc all >> without needing the tools listed. Perhaps someone could post an >> example from current build where these are used. > > By chance ;-) I have collected a list of modules that currently leave > the simple path of "just some c++/Java/src/idl compiling and that's it". > I think we should investigate their current makefiles and see how they > translate into systems using one of the possible candidates. Tomorrow I > will add this list to the wiki page Björn has started. Done. I hope that by investigating the makefiles of the modules at the top of the table we can identify the "dark magic" Björn has mentioned. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] New Build System Requirements
Jussi Pakkanen wrote: > On Tue, Feb 2, 2010 at 5:32 PM, bjoern michaelsen - Sun Microsystems - > Hamburg Germany wrote: > >>> There is also "Pure CMake". But as I said earlier, it is probably >>> smarter to first go "CMake + Unix" and then transition to pure CMake. >> >> You are severely underestimating the dark magic done in the build >> system (mostly concentrated in a few "ugly" modules"), if you believe >> all current ops can be done in "Pure CMake". There are some pretty >> mystical textprocessing operations done using sed, awk, perl etc. >> throughout the build. > > I want to note out the following so no-one will think that I am a > religious zealot: > > CMake *will* take more work up front than GNU Make (which, as I > understand, already works). It works for some modules, yes. Amongst others for "sw", so we have more or less covered everything that you can find in "normal" modules. We still have to do a lot of work for all the modules that are "different". Please see my mail about the module build targets investigation. > It may be a lot of work, it may be a sh*tload of work. The advantage of CMake is that we have to code only for one "platform": CMake. With GNUMake we surely have to do more "porting". The advantage of GNU Make is in the troubleshooting. >> Going for "Pure CMake" is going to be a lot of >> work and is spoiled if it cant be completed as there is little worth in >> "mostly pure CMake". To request resources for such a project on the >> prospect that it "will probably work out" is unlikely to work out >> with any of the big supporters of OOo. > > I don't think you can ever get rid of Cygwin completely. At the very > least you need Flex and Bison and the easiest way to install them is > to use Cygwin. Then you might as well install other tools as well. > "Pure CMake" was mostly listed for completeness. I guess it should > have said that transitioning to it can be done as an independent step, > at a later time, and only if it is deemed necessary at the time. And > most importantly: you get CMake's benefits even if you never do it at > all. I tend to agree that - whatever we will do - we probably won't get rid of cygwin. Where we have to get rid of it is the building of the "normal" modules. As an example, if a developer is going to work on "sw", he might want to build sw and all c++ libraries it depends on (well, without the external ones). Being able to do that in Visual Studio would be a tremendeous achievement. But using Visual Studio as a "launcher" for cygwin shells is probably not what we want here. So the build of "normal" C++ libraries should run inside VS completely. Building other modules like extras, helpcontent etc. with Cygwin won't hurt in this scenario. But it might have some negative influence on the performance of a complete build if vcbuild is used as the "launcher" for several cygwin shells that we will need to build the "special" modules. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] New Build System Requirements
Jussi Pakkanen wrote: > Another point is "However, there are many cases where the current > build process depends on a large set of external tools like bash, awk, > findutils, coreutils." Does the actual building require these or is it > more of a case of "need these, because dmake/build.pl needs these"? In > my OOo CMake experiment I built idlc, generated urd, Java etc all > without needing the tools listed. Perhaps someone could post an > example from current build where these are used. By chance ;-) I have collected a list of modules that currently leave the simple path of "just some c++/Java/src/idl compiling and that's it". I think we should investigate their current makefiles and see how they translate into systems using one of the possible candidates. Tomorrow I will add this list to the wiki page Björn has started. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] New Build System Requirements
Thorsten Behrens wrote: > bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: >> I started a new wikipage here: >> http://wiki.services.openoffice.org/wiki/Build_Environment_Effort/New_Build_System_Requirements >> >> collecting the major requirements for a new build system and what needs >> to be done to implement these requirements with GNU make and CMake >> (those two currently seem to be the only serious contestants). If you >> find additional requirements, feel free to add them to the page. >> > Nice page, thanks Björn! > > Though I think the section about debuggability appears a bit, err, > skewed - I would think none of the contestants are "easily > debuggable" to the common man, when it comes to the internals. ;) I agree that for the "common man" most non-trival makefiles ar hard to understand, let alone debug. But IMHO it's a fair assumption that understanding/debugging only one file is easier than doing the same for two (the generator and the working file). If a build breaks due to a makefile, you first have to the root cause in the "native" make file, and in case of a CMake/OOo combo it means that for OOo you must be able to do that in two different systems (GNU Make and vcproj). Then you have to find out what caused the problem in the CMake makefile and how to avoid it. That's definitely more work to do than doing the same in a GNU makefile alone. This doesn't rule out CMake as a serious competitor, but it shows that its main benefit (being able to build with VS on Windows) comes at a price. > Having lean dependencies is also nice, but more of a runner-up > criteria for me - it would prolly only make a little dent in the dep > list OOo has anyway... Well, we have to start somewhere, haven't we? Lately I gained some experience with dependencies in OOo and reducing them. IMHO it's easier to understand how the different parts of OOo work together the more the complexity of the dependencies is reduced. This helps new developers to understand. And even the more experienced developers benefit from the better maintainability. So I think that aiming for leaner dependencies (not only) in the long run is a worthwile goal and I wouldn't consider any change in the build system that wouldn't go for it. Whether it's the number one or the number two priority doesn't matter for me: IMHO it's a must have priority. As always, YMMV. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
Stephan Bergmann wrote: > On 01/27/10 09:07, Mathias Bauer wrote: >> Jussi Pakkanen wrote: >>> Yes, sure. If and only if you have target_link_libraries(some_exe >>> some_library) then the linker invocation for some_exe will have >>> '-lsome_library'. Whether or not it was built accidentally, CMake will >>> not link the exe against the library. >> >> Cool. > > Mathias, I'm not sure I understand your excitement here. ;) Ehm, yes. :-) Reading it a second time I must have misunderstood what Jussi wrote. But this wasn't the first misunderstanding in this thread. :-) I thought that he wanted to point out that CMake will quit working in that case, even before the build starts. Though in fact that seems to happen as he explained in his last mail, the quoted text above indeed was something different. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
ot specified (and evaluated) in the makefile of B and C but in the makefile of D by including the makefile of A directly. >> BTW: how does CMake organize the parallel build? The "all in one >> process" approach has another major advantage: as it is one process, it >> can find the optimum distribution for the available processes. This is >> not possible if the build runs in several processes, even if they are >> called recursively. > > Again I don't know about the implementation. But when I run 'make -j > 17' on a 16 core machine and then run top, I get 100% CPU utilization > almost all of the time. So it definitely "works for me". Whether it > does for you is a matter of testing. How good the build scales depends on the stuff to build. But OK, I think we will figure that out. Thanks for your answers, now it's time to try your example and then talk with Martin about his findings with our source code. I will report back. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
Hi Jussi, before we continue let me add some words to avoid misunderstandings. In no way I'm trying to cast a bad light on CMake or want to defend our trial approach "just because". But before I consider to support a different approach I want to get the essential problems discussed in the same depth as we did it ourselves when evaluating the GNU Make approach. If CMake solved our essential problems it could be a nice alternative as it gives us the additional benefit of possible "native" builds on Windows (I assume we could still choose to use GNU Make also on Windows/Cygwin for now). Of course, TANSTAAFL: I'm sure we will be the first to explore this (native Windows builds with CMake) for a project of such a big size and diversity. Surely we will find many "interesting" problems. But that shouldn't stop us from discussing it now. :-) Jussi Pakkanen wrote: > On Thu, Jan 21, 2010 at 10:50 AM, Mathias Bauer wrote: > >> So, how can we implement "include, not execute" with CMake? > > You can do this, if it is absolutely necessary. I'll describe that at > the end of the message. > >> Consider that you have the modules A, B, C and D. D depends on B and C, >> that both depend on A. This is reflected by corresponding entries in the >> build.lst files of these modules. Let's assume what happens if I forget >> to add the dependency on A in the build.lst from C. >> >> When I do a complete build from scratch for module D, it will work if B >> is built before C as building B will also build A, so C got its >> precondition met and will build fine also. If C is built before B, the >> build will break as it will miss A. > > CMake has no concept of "modules" as used in OOo. My understanding is > that a "module" is roughly one subdirectory (or as defined in > build.lst) that produces one or more libraries, executables and so on. As I wrote, it doesn't matter if we are looking at "modules" or single targets (libraries, jar files, executables etc.), the problem is the same. I just started with "modules" as this is what we have now. > In CMake all dependencies are between deliverables (i.e. libraries, > binaries, etc). Subdirectories are just a convenience. So in your > example we would have in subdirectory A something like this: > > add_library(A SHARED sourceA.cxx) > > Then in B you would have > > add_library(B SHARED sourceB.cxx) > target_link_libraries(B A) > > Similarly in C you would have > > add_library(C SHARED sourceC.cxx) > target_link_library(C A) > > And finally in D: > > add_executable(foo source.cxx) > target_link_library(D C B) > > What happens if we change C to accidentally remove the dependency to A? > > When make is run, it will produce a link error for C. It will not use > a stale library file one you may have in your build tree. Thus the > error will be immediately apparent to the person doing the change so > he will not check in code that will break on other people. Sure? What if you do a parallel build and "by accident" the library A is built before C is linked? That's exactly what happens in our current build system. For this trivial example it is close to impossible that a bug like this one stays unnoticed. But the multitude of targets and dependencies we have in OOo makes it much more probable to happen. And experience proves that: it happens at times and is a major PITA. The step forward in the "all in one process" solution is that the possible link error is detected in the process of checking the dependency tree, regardless how much stuff is built afterwards and how many parallel processes you will use then. I still can't see how this is done with CMake. It's totally possible that this is my fault. ;-) The CMake documentation isn't very helpful here. I can mainly see very trivial examples, nothing that comes even close to the complexity we have in OOo. Beside that I wouldn't be astonished if CMake couldn't do that - in my current (admittedly limited) understanding CMake never is meant to explore the whole dependency tree from top level binaries down to the included header files (or even further in case they are generated from other sources). That's what happens in the created "native" makefiles. Or does CMake double that effort and evaluates all dependencies by itself before the "native" makefile does the same again? > I tested the behavior just now with a sample to make sure it actually > does this. I can send a sample project if someone wants to try it > themselves. I would appreciate to be able to get my hands on it. :-) Trying is so much better than talking. Until now I only found rather trivial examples in the
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
that I have described above is not there. Moreover, a missing rule will be detected even before the build starts, so mistakes are found faster: it is sufficient to call "make" with an empty solver to detect the missing rules. So unless you can't bear the overhead of evaluating all dependencies all the time (what hopefully will take less time than running through all modules today), you can always just call "make" after your changes anywhere in the code and the result will be OK. (I've put aside for now what make will produce at the end: just a solver, packages/installation sets or a runnable office instance somewhere - that doesn't matter here.) Of course it is still possible to create wrong makefiles, but a very important error (that happens quite easily in our current system) will be removed. What does that tell us about CMake? If CMake does not allow us to use a "super makefile" including all other makefiles, we don't get the build stability improvements that the GNU Make approach can give us. In case we can have a "super makefile" that *executes* the others (recursive approach) we have at least an improvement because this file will be the replacement for all build.lst files. But still the only way to find missing dependencies/rules is executing the build and hope that the errors are not masked. So again: how can we implement "include, not execute" with CMake? Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
Thorsten Behrens wrote: >> Given that the syntax of the "build task description language" should >> be simple (because, if one needs it to be complex, one is likely Doing >> It Wrong(tm)) I wonder, if something that can be processed by the >> POSIX-shell or the C-Preprocessor would not be possible too(*). >> Actually, I am rather confident that would be possible. >> > Likely. There are two reasons I decided against using those: > * ugliness (I have yet to see the cpp macro program that does not >hurt my eyes) > * too much expressiveness (you'll get full turing completeness >easily, when you process stuff with the shell. I explicitely >wanted to keep things declarative, and prohibit those small local >if-then-else workarounds) "Ugliness" is in the eye of the beholder, but simple declarations instead of more or less complex expressions are indeed valuable. Let's see what we can do in the way Björn suggested. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
Thorsten Behrens wrote: > bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: >> > But the actual information contained in the above lines is actually >> > this: >> > >> > rscdep source files: tools/bootstrp/* >> > rscdep link libs: tl >> Quoting a band from Hamburg: "Jein" (=Yes and No). >> Of course, there is a lot of superfluous syntax in the current >> description, but you are dropping some information too: >> - Where is the information which naming convention the tl-lib is >> following? >> > That information is implicitely already contained in the name 'tl'. > As you notice further down, the gmakegen script has a static map for > those lib names. > >> - What about the files in tools/bootstrp, that are not generating >> object files that should be liked into rscdep (sspretty.cxx for >> example)? >> > Yeah, badly chosen example. The absolute majority of OOo code _is_ > organized in a fashion that allotting sources files to libs works on > a per-directory basis. At any rate, the generator script can do > both. I don't think that we must keep the bad habit of having source files of different libs in one directory. We can easily fix that on demand, so this shouldn't be a roadblock for anything. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
Jussi Pakkanen wrote: > On Mon, Jan 11, 2010 at 7:57 PM, Thorsten Behrens wrote: > >>> functionality? Even if CMake eventually turns out to be too slow, >>> would it not make more sense to write your own custom CMake back >>> end rather than the configuration/generation front end? >>> >> I guess it's now my turn to ask for sample code here. ;) > > For a backend? No, sorry. I have never looked into that. > > But the issue raised earlier was that because CMake's Makefiles are > recursive (or something) they are too slow, probably because automake > does it this way and is slow. I personally do not think this will be > an issue. When running on Windows, the time taken by makefiles when > changing directories is insignificant compared to the time taken by > the compiler. But I have only tried it under Virtualbox and not at all > thoroughly. The problem is not because the makefiles "are" recursive. The problem is that it looks if CMake does not offer a way to include all makefiles of the whole project (or at least larger parts of it if you think about a split build) into a single process without clashing of target names. So the only way to reuse CMake makefiles for a complete build is recursively calling them or - as we do today in OOo - serialize the process. I don't think that this is a matter of performance per se, it's just that the benefit is missing we wanted to get from the new "single make process" approach. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
Thorsten Behrens wrote: > Mathias Bauer wrote: >> So if you could explain how bjam (or any other make system that >> someone wants to suggest here) solves our problems or why the >> problems that require bjam to be resolved are even bigger than >> those we try to fix, we might be able to get somewhere. >> > I did that, if you could check my initial posting. Bjoern said he > profiled gnu make with large enough synthetic rule sets, point is > settled for the while, I'd say. OK, so I misunderstood your intention for mentioning bjam. >> You can find most of our findings, discussions etc. in the wiki (I have >> posted the link several times) or in Björn's and my blogs. >> > Nothing we're discussing here except Bjoern's initial blog from > Friday, sorry Mathias. This is not to criticize anybody, just > pointing out that, when such things are announced after-the-fact, > many of the stupid ideas & questions that have probably been > resolved internally before, will crop up in the public discussion > again. Do you really believe that posting the "stupid ideas and questions" would have prevented that they crop up in the public discussion? :-) >> Björn also will post some more data about GNU make investigations >> soon. They never were planned to be "internal findings", but >> posting them without prior explanation wouldn't have made sense >> and even now they don't add anything to the discussion we wanted >> to start. The topic is not "can GNU make do that", but "do we have >> the right goals" and "GNU make can reach the goals, which other >> tools can do it also or perhaps even better". >> > Understood. I pretty much agree with the goals, assume you did your > due diligence on verifying that gnu make does not trip over on the > full input set (that was my point of cautioning you, with the bjam > story), and am now trying to explore ideas on how to make the actual > makefiles appealing - the current state is not convincing, just > plainly because they're not substantially different from the ideal > dmake makefile in the existing system - and with their redundancies, > will suffer the same bitrot as the old system. Sounds good. :-) Any improvement would be welcome. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
Thorsten Behrens wrote: > Hi Mathias, > > most of the points you've raised I already replied to in my followup > to Bjoern (including my ideal msword lib makefile) - > > Mathias Bauer wrote: >> build.pl uses module dependencies, not target dependencies, so it has an >> inherent susceptibility to bottlenecks. Basically all of our c++ sources >> could be built in parallel (as they don't depend on each other), but >> with build.pl we always have to wait until header files are "delivered" >> or created. And because the dependency granularity level is the "module" >> (not a real target like e.g. a library), we can't use as much >> parallelization as possible. This becomes even more painful if you don't >> build the whole office, but only some parts of it, e.g. in a split build >> or if you rebuild several "modules". >> > Ah interesting - so we're then moving away from the solver concept? This is irrelevant for the system in question. With or without solver, you will have the same problems with our current build system. The only thing that matters is how many modules you want to build in parallel. > >> No, really, there's nothing nailed until now. If you or anybody else >> knew a better way and(!) offered help and cooperation, there's nothing >> that would hold us back from doing it differently. >> > I find this "and(!)" slightly worrying - not that I would not lend a > helping hand; but why are you refusing advise from people just > because they may not have time helping you with coding? Did I say that we would refuse advise if it clearly showed improvements? Of course not, why should we? But I wouldn't call "don't use X, Z is much better" an advise. Or, to say it with Monty Python: "This is not an argument, this is contradiction." "No, it isn't!" "Yes it is!" etc. etc. Perhaps I should rephrase my statement: the best I can see is that people show us that what we want to achieve by using GNU make can be done even better, simpler, faster etc. in a way we don't know until now and help us to get that implemented. As far as I'm concerned, the second part is optional, but of course much desired. >> > That's why he went for bjam ... >> >> Can you explain if bjam is able to fulfill the requirements Björn and I >> have mentioned and what else it can do better than GNU make? Or can you >> at least explain why you perhaps prefer it? >> > I didn't say I'd prefer it. I was just pointing to that project, and > the experiences. Just pointing to a project without giving a hint how that could solve the problems isn't very helpful ATM (though I appreciate the hint and surely will have a look when I have some time). So if you could explain how bjam (or any other make system that someone wants to suggest here) solves our problems or why the problems that require bjam to be resolved are even bigger than those we try to fix, we might be able to get somewhere. > Maybe it would help the discussion if more of the > internal findings you mentioned would be public - come to think of > it, maybe it would have been nice to have the whole discussion that > led to this prototype public, in the first place ... ;) You can find most of our findings, discussions etc. in the wiki (I have posted the link several times) or in Björn's and my blogs. Björn also will post some more data about GNU make investigations soon. They never were planned to be "internal findings", but posting them without prior explanation wouldn't have made sense and even now they don't add anything to the discussion we wanted to start. The topic is not "can GNU make do that", but "do we have the right goals" and "GNU make can reach the goals, which other tools can do it also or perhaps even better". Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
> newcomers for a simple build without changing anything. But I leave it >> to you to explain to release engineers, why it is their job to translate >> the changes made by a new dev in his IDE-project back to the cmake >> source. They will rightfully refuse that. Thus the newcomer will have >> to fiddle with the makefiles again manually, winning nothing in the end >> (other than additional confusion and probably some needless >> communication on mailing lists). >> > Yes. And? It's still significantly lowering the barrier of entry. > Loads of other projects do it (with the same limitation). And the > need to add a new file to the project is usually not the first, not > the second, but the nth thing you do when starting to hack ... If you think that calling "make" is a barrier, overcoming this is easy. Many developers have configured their IDE to start the OOo build process from it. But that's not what I would call an IDE integration. This would require to make OOo a "project" of the IDE. As Michael Stahl stated, we have done some first tests, and the results where so disappointing that we didn't continue. It seems that neither MS Visual Studio nor NetBeans is able to handle even the single writer project (writer sources and headers from "solver") with an acceptable performance. We could do the same test with Eclipse, but I doubt that any IDE is able to handle larger parts of OOo, let alone the whole source code. That really would create the "pathetic" performance and the "ridiculous memory usage" that you are afraid of. So an IDE can't be the solution for the build system. Of course it's something that we should keep in mind (and we do) as an addition. Building smaller, well separated "modules" of OOo in an IDE is surely possible, and especially being able to build extensions that way is one of my oldest requirements for our SDK. But this is an addition to a reliable build system for the whole project, nothing more. I don't see contradicting, but supplementing requirements and solutions here. If you think that this is so important, we will be glad to work with you to get that implemented. > So stepping back a bit, I should probably mention (again) that I > find the general idea really great - the make system is truly > arcane & leaves a lot to desire. But despite your initial request for > input, plans & thoughts, I cannot but have the impression you're > already quite determined to follow the outlined route - sadly the > build system has seen quite a few attempts for change; and survived > all of them ~unmodified, thus some extra thought & consultation is > surely advisable ... No, really, there's nothing nailed until now. If you or anybody else knew a better way and(!) offered help and cooperation, there's nothing that would hold us back from doing it differently. The more people get involved and the broader the consense, the better. Currently we have only published our most important requirements and a prototype for how they could be fulfilled. > From my humble point of view, what has usually worked best in OOo > land is some iterative approach to change; which in this case & my > opinion would mean cleaning up makefiles one by one, either using a > declarative DSL directly that could later be mapped to gnu make or > whatever tool we see fit, or - using a meta-language like automake > cmake, or something homegrown, *still* use dmake for the while, and > then, after some critical mass has been attained, switch the make > tool wholesale (and adapt the metalang-to-makefile generator). That iterative approach is exactly what we want to do also. At least the GNU make builds fit nicely into the build.pl process, as Björn already has tested, we can convert each module step by step. Of course the big benefit will require to do the whole thing at the end. > Additionally, and since you mentioned the desire to have only one > make instance - last time someone tried to have gnu make hold all of > OOo's dependency tree in one process, that guy (Kai Backman) ended > up with absolutely pathetic performance & ridiculous mem usage. IIRC Kai didn't use GNU make, but jam (that according to Kay Ramme is not able to deliver what we need). And what was "ridiculous mem usage" seven years ago, nowadays is probably just a little bit more than average. The scalability tests Björn has done for GNU make made us think that this won't be our problem. Most of our dependencies are header dependencies. The additional dependencies on other prerequisites are important (and - as I wrote - are the PITA in our current system) but not so numerous. So what we have seen in our prototype (where the header dependencies have been pretty complete already) didn't sho
Re: [tools-dev] Comments on Mathias blog post about contributing
Sophie wrote: >> Whether help content must be part of a feature CWS or >> not should be seen in the general context of how we want to localize it. > > Not only, sometimes changes are not documented because the corresponding > CWS has not been mark help relevant, having an issue in the CWS tasks > list would help to make sure (or at least give a chance that) it will be > documented in the same release the CWS is integrated. Ah, that was what you where pointing at! Yes, good point. > We have already talk about improving the process on the l10n list and at > the last OOoCon also. See the thread here : > http://l10n.openoffice.org/servlets/ReadMsg?listName=dev&msgNo=10607 > As said, I'm not technical enough to know what would be the best tools > and process, but I'm used to SCM and I can understand the benefits we > can gain here. So what you described above using Mercurial is a kind of > dream I'm sure all l10n teams would like to see happen :) > > It may be not relevant for the discussion here, but we have had to fight > against integration issues, formatting issues, development issues, > etc... I've spent hours translating strings that were not integrated or > seen changes finally reverted. > So for me it's not only a localization process issue but a better > coordination/communication between the development process and the > localization process. I have just outlined a "skeleton" of what I could imagine as (dream of?) a localization process. The nasty details will be interesting to discuss. I think that the less steps we have between the files that we are using for a localized build, and what a localization developer actually uses to provide his work, the better will be the result. But I agree with Jörg, this will take time and if smaller improvements can be done before, we should be glad to get them. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Comments on Mathias blog post about contributing
Jörg Jahnke wrote: > Hi Mathias, > > Mathias Bauer schrieb: > ... >> >> Currently the way how localizations get into OOo is very inefficient. At >> some point in time a "deadline" is reached and a whole bunch of >> localizable content is exported from the source tree and handed over. >> Localizers do their work, send it back and have to wait until Sun >> release engineering has collected it and provided a new build containing >> all the work. If bugs are found, the next round follows. I think we can >> do better. >> >> My idea for a long term goal is that all localization related content >> (help, UI etc.) resides in an own Mercurial repository that localizers >> can check out and directly commit to (if they want). A *simple* build >> process (that does not require to check out the whole OOo source) allows >> them to test their results themselves and immediately correct errors, >> but that would be optional. Of course it should still be possible to >> work as today (send changes to Sun release engineering), comparable to >> the situation of code contributors that either can create an own CWS or >> send in patches. >> >> In a system like this localization even does not need to have a >> deadline. Once a feature is done and documented, it can become >> localized. Whether we want to do that is open for discussion. > > Even with the current L10N process this increased flexibility, that you > seem to have in mind, can IMO be reached, since it would be possible to > import the new and changed strings from every milestone into the Pootle > system used for translation. But a little more automation should be done > in order to reach this goal since doing these imports manually is quite > time consuming. Then translators could continuously work on the translation. > > Getting the translations back into the code still requires a CWS. This > work is, at least at the moment, done by Ivo or Vladimir, and they do it > for all languages, saving the L10N teams a lot of work IMO. Currently > such an L10N CWS is created once per release, which means that > translators get feedback on their work quite late. This frequency could > be increased, and I know that Ivo has spent some work on automating the > processes around creating an L10N CWS in order to create these CWS more > often, but AFAIK there still remains some work to do. > > So, while I think you did draw a valid picture of an L10N build process > above, I think we could improve the situation with far less changes to > the current processes and thus far less work. IMO we should try to > implement the improvements I sketched out above first and then see if we > have to go a step further and perhaps change the processes as you > outlined above. Sure! Every improvement helps. And if we can think about how we can get rid of all the intermediate steps in the long run, that would be great! If I just look on the matter from an exernal POV, I don't see why localization contributions should be treated differently than others. Code developers either create a CWS or send in a patch. Localization developers currently only have option 2, even if they wanted to use option 1 in case they can cope with it. Moreover, they can not even test their patches in a running build, they have to wait for a build done by Sun Releng - what a difference to code contributions! Having both options would be a worthwile goal for the *future* because it reduces the turnaround times and also the number of necessary turnarounds dramatically. And "the future" is what we are currently discussing. Please don't get me wrong, not everything what I have written means that I want it all and I want it now. :-) Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Comments on Mathias blog post about contributing
Rene Engelhard wrote: > Hi, > > On Wed, Sep 23, 2009 at 11:39:49AM +0200, Michael Stahl wrote: >> or maybe we could simply have a "convenience" flag for configure like >> --official-build, that would simply behave as if the set of necessary >> non-default flags were given? > > That would need Sun people actually touching configure when they > change their defaults. Which they do not do (and neither tell the > people maintaining configure..) and thus configures defaults > always run behind (and there is Sun defaults you don't want to have > as default in a "normal" build, like all the extensions) You might be pleased to read that in fact we are still planning to fix that. There is no "ready" date we could promise now, but it is on our list and it is in the upper part of it. Besides that, it's not only using configure or not that makes a difference in the resulting builds, of course the "base line" and the (system) libraries linked against are important also. I assume that you know that, so this is just for completeness in case someone not knowing that is reading our discussion. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Comments on Mathias blog post about contributing
Helge Delfs - Sun Germany - ham02 - Hamburg wrote: > Hi, > > On 09/23/09 08:29, Mathias Bauer wrote: >> Really, this part of the work is superfluous. IMHO tests that are known >> to be broken in a particular milestone should be skipped in a CWS based >> on it also. So if you get a "red" state, you know that something is >> wrong without the necessity to browse through Quaste. I hope that this >> will be changed, but I don't know what the Sun QA engineers working on >> the autotests are planning. The testing procedures themselves are not >> part of our effort to improve the build environment, so I can only guess. > > One should use here a more granular argumentation. If a test has a red > state it must'nt have the same cause that leads to this. There might be > another reason for this. I maintain my point that the price we have to pay for this tiny little piece of information in the rare cases where we really have an additional reason for the failure is too high. This is looking for perfection in the wrong area. > QUASTe has an overview page it's called 'Analyze errors' that only lists > the differences between testresults on MWS and CWS with the same > milestone. So it is fast and easy to get an overview and compare > testresults. > This page can be reached by choosing a platform and page 'Testresults > grouped by application' has a button 'Analyze errors'. I know that finally you can find out if an error is "real" or not, but that's not the point. It shouldn't be necessary. And I wouldn't call that "fast and easy". But as this does not touch the build environment and nobody asked to change something (it was just my private opinion), we can leave that for now. Let's agree to disagree. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Comments on Mathias blog post about contributing
Frank Schoenheit, Sun Microsystems Germany wrote: > Hi Mathias, > >> Really, this part of the work is superfluous. IMHO tests that are known >> to be broken in a particular milestone should be skipped in a CWS based >> on it also. > > Don't think this is a good idea, since a test can be broken in different > ways. For instance, if your test checks 10 aspects, and one of them is > broken in MWS, you still want to know if the other 9 are okay in your > CWS. Otherwise, you'll notice a breakage in those 9 only when the one > failure is fixed, and the whole test re-enabled in MWS. Then the granularity of test is wrong. As we have limited resources, we must not waste our time. It's better to skip a particular test (hopefully in a granularity so that not too many "aspects" are dropped) for some milestones and fix the root cause for its breakage ASAP then wasting so much time as now. Of course fixing the breakage must get high priority. > An interesting read (IMO), somewhat related to the topic: > http://blog.ulf-wendel.de/?p=259 (sorry, German, but I know you speak it > pretty well :) > My favoite quote, which I'd strongly agree to: > > Deactivating a test, to reach "0 test failures", is wrong, since the > equality of a failure is also a sensible information. Just because someone blogs it doesn't mean that it is correct. There are a lot of blogs available. :-) Or in short words: I don't buy that statement. "Information" comes at a price and it must be taken into account if you don't have unlimited resources. We could keep the test if the status page clearly would show me "test run gave the same result as the master test". The waste in time would be smaller then (a broken test doesn't take a lot of time, the waste comes from manually checking the results as we have to do now). But I take every bet that everybody would do the same with the "sensible information" that the master has the same failure as the CWS: read it and forget it. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Comments on Mathias blog post about contributing
Hi Sophie, thank you for your comments. I'm glad to get feedback from "non code hackers" also as I'm hoping to make life easier for them also. I will add your points to my list. Let me give some immediate answers to some of your points. I will come back if I can say to one of the other points I have put on my list for now and snipped in my reply. Sophie wrote: > What a community member like me has the most to fight with when doing QA > is time. It's not very hard to check for issues, to run VCLTestTools or > write TCS, but it takes a lot of time for each (and also a lot of time > to learn to do every thing the right way, but it's really a very good > experience thanks to the e-team I've worked with :). > > Tools are not so difficult (for a non technical person like me) and I > found that dealing with EIS (the QA part) is really helpful. > The good points : > - Termite to build install sets > - Ability to run the Automation CAT0 on Sun servers > - Direct upload of the tests results on QUASTe > - Comparison with MWS, you just have to run again the fails locally. Really, this part of the work is superfluous. IMHO tests that are known to be broken in a particular milestone should be skipped in a CWS based on it also. So if you get a "red" state, you know that something is wrong without the necessity to browse through Quaste. I hope that this will be changed, but I don't know what the Sun QA engineers working on the autotests are planning. The testing procedures themselves are not part of our effort to improve the build environment, so I can only guess. > - EIS allow a very good coordination between all of us. > All this chain is really time saving (your own machines can rest ;) Thanks, it's good to get some positive feedback also. :-) > Concerning the localization process. Well, we still have a lot of things > to improve from my point of view. A better communication and > coordination with developers may have its place here more than our usual > complains against Pootle. So yes, > - helpcontent should be part of the concerned CWS, if it is mark that > the help is concerned, then the corresponding task should part of the > CWS issue list > - there should not be a new CWS added to SVN with no spec or a detailed > issue Well, we always advertized the value of specs, it's good to read that this opinion is shared by those who we saw as "consumers" of specifications. Whether help content must be part of a feature CWS or not should be seen in the general context of how we want to localize it. > - I support your idea of working with SCM, if well documented I'm sure > we will be able to get the support of other l10n teams to work on CWS > and mercurial, and more if that avoid us all this mess up in the last > snapshots. Currently the way how localizations get into OOo is very inefficient. At some point in time a "deadline" is reached and a whole bunch of localizable content is exported from the source tree and handed over. Localizers do their work, send it back and have to wait until Sun release engineering has collected it and provided a new build containing all the work. If bugs are found, the next round follows. I think we can do better. My idea for a long term goal is that all localization related content (help, UI etc.) resides in an own Mercurial repository that localizers can check out and directly commit to (if they want). A *simple* build process (that does not require to check out the whole OOo source) allows them to test their results themselves and immediately correct errors, but that would be optional. Of course it should still be possible to work as today (send changes to Sun release engineering), comparable to the situation of code contributors that either can create an own CWS or send in patches. In a system like this localization even does not need to have a deadline. Once a feature is done and documented, it can become localized. Whether we want to do that is open for discussion. We are far from that idea - one necessary precondition for it would be to free our l10n builds from using the OOo Resource Compiler and I'm sure there are other obstacles, but basically I don't understand why it shouldn't be possible. As the localization is very important for OOo the effort to improve its process surely would be justified. What do you think? Of course I don't want to impose something on others, but perhaps many people would like to work in such a faster and more flexible way, even if it needed some work on the build environment and some change in working style of the l10n teams. Maybe nobody dared to ask for that because it was considered to be improbable that something like that could be implemented? Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.or
Re: [tools-dev] adding a new prerequisite
Martin Hollmichel wrote: > Hi, > > for fixing issue http://www.openoffice.org/issues/show_bug.cgi?id=94560 > is will be required to have for the build of OpenOffice the > redistributable package at hand for compiling the install sets (cws dv07) > Since this issue is not an issue a developer is confronted with I would > opt to introduce the check of this prerequisite as an warning only in > configure, so that it will not be required for newbie builder to have an > additional binary blob required for the build, Basically this is a good idea. But we should make sure that building in instsetoo_native will give a hint what needs to be done, very much in the same way as configure does it in most cases. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Yet another commit to a master that was annoucned long ago. When will we have pre-commit hooks that prevent this?
Christian Lohmaier wrote: > Hi *, > > the summary says it all. > > Again there has been a commit to a master that was announced long ago. > This commit surely is unintended as were the other ones. > > So why is it so hard to setup a pre-commit hook that prevents commits to tags? It isn't hard, but it seems that those who had to do it refuse to do so. > PLEASE fix it. +1 Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Integrating Sphinx in openoffice
Hi Malte, Malte Timmermann wrote: > PS: Not sure, but I think [EMAIL PROTECTED] might be the better > places for this.. Are you sure that there is still someone listening on that list? ;-) Perhaps [EMAIL PROTECTED] or [EMAIL PROTECTED] is better. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo 300 m9 Windows configure error
Hi, My impression was that you are using the Express version and this does not have atl support (AFAIK). Nice to hear that you got your problem solved. Ciao, Mathias dooteo wrote: > Hi Mathias, > > At the end, I have not disable ATL, I just redefined correct paths for > configure to build with ATL :) > > Thanks, and best regards, > > Dooteo > > Jatorrizko mezua: az., 2008-11-05 16:04 +0100, egilea: Mathias Bauer >> Hi, >> >> to get rid of the atl header problem on the ooo300 code line you have to >> manually set the environment variable DISABLE_ATL to "TRUE". For the >> DEV300 code line this has been fixed meanwhile and there you can use >> --disable-atl in configure. See >> >> http://wiki.services.openoffice.org/wiki/Building_OOo_with_Cygwin_on_Windows#Setting_up_the_build_environment >> >> Ciao, >> Mathias >> >> dooteo wrote: >> >> > Hi Raman, >> > >> > There was a typo in my configure :) >> > >> > But, vy the other hand, there is an error about ATL headers (atlbase.h >> > and atldbcli.h not found). Did you disable them after configure step is >> > done? >> > >> > >> > Thanks and best regards, >> > >> > Dooteo >> > >> > Jatorrizko mezua: lr., 2008-10-25 10:14 +0530, egilea: RKVS Raman >> >> I found no error. >> >> >> >> My configure looked like this >> >> >> >> $ ./configure --with-cl-home=/cygdrive/f/VSNET/Vc7/ >> >> --with-jdk-home=/cygdrive/f >> >> /jdk5 --with-use-shell=bash --with-ant-home=/cygdrive/f/apache-ant-1.7.1 >> >> --wit >> >> h-csc-path=/cygdrive/C/WINDOWS/Microsoft.NET/Framework/v1.1.4322/ >> >> --disable-bui >> >> ld-mozilla --with-lang=ALL --with-java --disable-odk >> >> --with-poor-help-locali >> >> zations="hi-IN bn-IN" --disable-mediawiki >> >> >> >> >> >> >> >> Please check your .Net Framework version. It has to be 1.1.4322. >> >> >> >> --- >> >> RKVS Raman >> >> BOSS Resource >> >> http://rkvsraman.blogspot.com >> >> http://www.bosslinux.in >> >> >> >> >> >> >> >> On Thu, Oct 23, 2008 at 5:03 PM, dooteo <[EMAIL PROTECTED]> wrote: >> >> > Hi all, >> >> > >> >> > I'm trying to build OOo 300 m9 in Windows XP 32 system. In the same >> >> > system I had no problem to build OOo 2.4 version. >> >> > >> >> > But now, in the configuration step (of 300 m9 version) it's not able to >> >> > found midl.exe nor csc.exe, even both are in the system (and their path >> >> > are into bash PATH enviroment var). >> >> > >> >> > Any suggest? >> >> > >> >> > Thanks and best regards, >> >> > >> >> > Dooteo >> >> > >> >> > >> >> > - >> >> > 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] >> >> >> > >> > >> > - >> > 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] > -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo 300 m9 Windows configure error
Hi, to get rid of the atl header problem on the ooo300 code line you have to manually set the environment variable DISABLE_ATL to "TRUE". For the DEV300 code line this has been fixed meanwhile and there you can use --disable-atl in configure. See http://wiki.services.openoffice.org/wiki/Building_OOo_with_Cygwin_on_Windows#Setting_up_the_build_environment Ciao, Mathias dooteo wrote: > Hi Raman, > > There was a typo in my configure :) > > But, vy the other hand, there is an error about ATL headers (atlbase.h > and atldbcli.h not found). Did you disable them after configure step is > done? > > > Thanks and best regards, > > Dooteo > > Jatorrizko mezua: lr., 2008-10-25 10:14 +0530, egilea: RKVS Raman >> I found no error. >> >> My configure looked like this >> >> $ ./configure --with-cl-home=/cygdrive/f/VSNET/Vc7/ >> --with-jdk-home=/cygdrive/f >> /jdk5 --with-use-shell=bash --with-ant-home=/cygdrive/f/apache-ant-1.7.1 >> --wit >> h-csc-path=/cygdrive/C/WINDOWS/Microsoft.NET/Framework/v1.1.4322/ >> --disable-bui >> ld-mozilla --with-lang=ALL --with-java --disable-odk >> --with-poor-help-locali >> zations="hi-IN bn-IN" --disable-mediawiki >> >> >> >> Please check your .Net Framework version. It has to be 1.1.4322. >> >> --- >> RKVS Raman >> BOSS Resource >> http://rkvsraman.blogspot.com >> http://www.bosslinux.in >> >> >> >> On Thu, Oct 23, 2008 at 5:03 PM, dooteo <[EMAIL PROTECTED]> wrote: >> > Hi all, >> > >> > I'm trying to build OOo 300 m9 in Windows XP 32 system. In the same >> > system I had no problem to build OOo 2.4 version. >> > >> > But now, in the configuration step (of 300 m9 version) it's not able to >> > found midl.exe nor csc.exe, even both are in the system (and their path >> > are into bash PATH enviroment var). >> > >> > Any suggest? >> > >> > Thanks and best regards, >> > >> > Dooteo >> > >> > >> > - >> > 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] >> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools-dev] Re: [council-esc] SVN migration status
Stefan Taxhet wrote: > [cc'ed [EMAIL PROTECTED]; please follow-up there...] > > Hi, > > Nils Fuhrmann wrote: >> * server preparation: >> - migrate available keys from CN nach svn.services.openoffice.org: >>open, needs discussion with Stefan > > Heiner contacted me with this idea. My proposal was not to migrate >500 > keys from the OOo main site. I recommended to contact the active code > committers and ask for the key or a pointer to the relevant issue with > the key attached. +1 for this. Let's get rid of keys that aren't used anymore. I would send a mail to the dev list of my project and assume that active contributors at least read this list regularly. We could also send mails to some other lists as well (dev, discuss, nl-lists...). In the worst case people that don't read any of these lists will ask us how to access the new repository. Ciao, Mathias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] Re: [go-oo.org Dev] patch framework up-streaming ...
Hi Michael, Michael Meeks wrote: > On Mon, 2008-06-30 at 10:55 +0200, Mathias Bauer wrote: >> >I would really like to kill the meme that quality can only be achieved >> > by making fewer code changes, and by making developers' lives >> > unreasonably difficult ;-) >> >> http://www.ellak.gr/pub/synedrio/2008/presentations/day1-main/1-venema-oss-security.pdf >> >> :-) > > As in Strategy 1: "Eliminate Programmers": "Make programming a million > times harder" ;-) > > Sounds like a great strategy ;-) Particularly since we're starting from > such an example of perfection in OpenOffice (security-wise) - even > changing a single line anywhere risks catastrophically injecting the > very first security hole ;-) > > But then - is secure code an explicit goal of OpenOffice ? does it even > appear on the radar ? is it even the most useful metric of quality ? > > "Remember, buggy software **works**, even when >it is riddled with security holes" > > If only that was true ;-) > > Regards, > > Michael. > don't take my reply too serious. I only found it amusing that the "meme" you quoted matched so nicely what I heard at that conference - of course with a humorous twinkle of the presenter. You should know me well enough to know that this is not *my* take on that matter. I also want to make it easier. Here's another quote that comes nearer to my perception: "Make everything as simple as possible, but not simpler." I think it was Albert Einstein who said that. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] Re: [go-oo.org Dev] patch framework up-streaming ...
Michael Meeks wrote: > I would really like to kill the meme that quality can only be achieved > by making fewer code changes, and by making developers' lives > unreasonably difficult ;-) http://www.ellak.gr/pub/synedrio/2008/presentations/day1-main/1-venema-oss-security.pdf :-) Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] How to checkout DEV300 branch correctly?
Hi Eric, Eric Hoch wrote: > Hi Mathias, > Am Thu, 05 Jun 2008 13:48:47 +0200 schrieb Mathias Bauer: >> Hi, >> >> Maho NAKATA wrote: >> >>> Hi, >>> How I can checkout DEV300 branch (OOo3) source code correctly? >>> >>> According to CVSROOT/modules, >>> "OpenOffice3" alias does not contain >>> "apache-commons hyphen swext tomcat" etc etc. >>> >>> I have been put source code for every milestone at: >>> http://ooopackages.good-day.net/pub/OpenOffice.org/sources/ >>> and almost every build was checked on MacOSX and FreeBSD. >>> >>> Could you please help me? >>> Thanks >>> -- Nakata Maho http://accc.riken.jp/maho/ >> Do you know >> >> http://wiki.services.openoffice.org/wiki/User:Kr/Concurrent_Checkout >> >> I use it all the time. For a CWS on dev300 it needs an additional fix >> that I could give you, but for checking out a milestone it is fine. > > > Thanks for the hint. I really didn't know that such a script > exists. > > But when I try to run it under Mac OS X I get the following error > message in Terminal: > > xdsl-87-79-55-98:test maveric$ ./conco.awk -v Master=DEV300 -v > Milestone=m17 > /usr/bin/awk: syntax error at source line 32 in function > queryMilestone source file ./conco.awk > context is > print "export > SOLARENV=./solenv">>> |& <<< Shell > /usr/bin/awk: illegal statement at source line 33 in function > queryMilestone source file ./conco.awk > /usr/bin/awk: illegal statement at source line 33 in function > queryMilestone source file ./conco.awk > > Yes, I am connected to the internet, as you can see I used the same > arguments as stated in the wiki and yes I set CVSROOT. I even tried > it with ssh tunnel but it still fails. > > I fear that it is because of the SOLARENV which may not exist in > Mac OS X so what exactly is SOLARENV? > > Eric > The script requires gawk and bash, perhaps you have used another awk or shell (like tcsh)? I must confess that I never used it on a Mac, only on Windows (Cygwin) and Linux. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] How to checkout DEV300 branch correctly?
Hi, Maho NAKATA wrote: > Hi, > How I can checkout DEV300 branch (OOo3) source code correctly? > > According to CVSROOT/modules, > "OpenOffice3" alias does not contain > "apache-commons hyphen swext tomcat" etc etc. > > I have been put source code for every milestone at: > http://ooopackages.good-day.net/pub/OpenOffice.org/sources/ > and almost every build was checked on MacOSX and FreeBSD. > > Could you please help me? > Thanks > -- Nakata Maho http://accc.riken.jp/maho/ > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Do you know http://wiki.services.openoffice.org/wiki/User:Kr/Concurrent_Checkout I use it all the time. For a CWS on dev300 it needs an additional fix that I could give you, but for checking out a milestone it is fine. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Jan Holesovsky wrote: > Well, my _only_ motivation for the split are the build dependencies - so if > we > end up with 20 (sub)packages, or 15, I don't really care :-) Also, the names > are not that big deal for me (though I personally prefer better describing > names, and a kind of structure in them). What is the real problem from my > point of view is that currently you cannot take just one of the projects, and > (when you have the dependencies installed) self-containly build it. Also, if > you look at eg. framework, you see stuff that is essential for the OOo > functionality (desktop) as well as one that can be omitted (binfilter). What level of granularity are you aiming at? I think that having separate packages for modules can work for many if we applied the necessary changes to scp2. Of course these changes will be more than some tweaking, it looks like a redesign to me. But there are some libraries/modules that are still very big and very intertwined with others. Making them available as separated packages with a reasobable size would require code changes also - and currently I don't see any activity going on to work on that. That's something I regret but OTOH I know that this is a resource problem. > But the approach of moving the modules between the projects is generally OK > for me. Just let's be careful not to end up in arguments like 'X: This > module needs to be built in project A, that way we'll have the smallest > dependencies. Y: Yes, but people in the project B know most about it.' :-) I don't understand who modules and projects relate here. Projects are completely irrelevant for modularization - we should use the modules as units for packages and try to bundle some smaller ones into one package so that the number does not become too high. But nobody wants a package "filter" or "utilities". > So - what can we do as the next step? Should I try to merge your and my list > to come up with the 'core' dependencies? Or could you, please? As long as the lists are project oriented and not module oriented we won't succeed. As alway, IMHO. :-) Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] overhaul the windows symbol->ordinal mapfile system (known as def-files)
Jörg Jahnke wrote: > Secondly there is a maximum number of ordinals per def file which we > might hit. That can easily be solved by cutting down the libraries. That's needed for the biggest ones anyway. :-) > According to the Wiki entry on DLLs > <http://en.wikipedia.org/wiki/Dynamic-link_library>, the overhead for > name lookup was much higher during old 16-bit Windows times, when the > name table was not sorted by name. With 32-bit Windows it is now sorted > by name, so that a binary search can be implemented, which leads to much > better results. Additionally the (small) performance penalty only occurs > once when a DLL is loaded. So in short words: whether we can use that depends on how much it badly influences startup performance. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] Git / SVN Source code repositories
Guido Ostkamp wrote: > Hello Jan, > >> On Wednesday 31 October 2007 20:05, Guido Ostkamp wrote: >>> I checked the mailing list and the Wiki and found a hint that a Git >>> repository for OOo should exist at http://go-oo.org/git. >> >> It was an experimental repository, and is still available at >> http://old.go-oo.org/git/ - go-oo.org server itself moved to a new >> location. Because of its experimental nature, it is _not_ updated to >> follow the current up-stream CVS. > > sorry for the late reply and thanks for your response, I truly regret that > it isn't updated. > > As it got silent regarding the SCM topic on this list, do you know whether > all plans to replace the dreaded CVS by something better have been > cancelled? Nothing has been canceled, currently comparisons of different candidates are carried out. See http://wiki.services.openoffice.org/wiki/ESC_minutes#Face2Face_meeting_in_Hamburg_2007-10-29.2F30 Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] Problem with solenv/bin/linkoo in SRC680_m235
Oliver Braun wrote: > Mathias Bauer wrote: >> Oliver Braun wrote: >>> What are the reasons (again) why shared libraries and dlls aren't directly >>> created in solver instead of the modules local output tree ? >> >> I assume mainly the fact that Hamburg developers don't have write access >> to solver when building non-locally. ;-) > > For CWS's they usually do have write access. Yes, but you didn't ask for a *good* reason, you asked for *the* reason(s) and the whole "build in local tree and deliver" stuff is much older than the CWSs. :-) > I could also live with making > $(SLB) depend on some environment variable, so that building to solver is off > by > default: the build system is a much more appropriate place for this than the > product code. > >> Besides I think it's just because nobody asked for it and now it's quite >> some work to change the build system in a way that "deliver" is >> incorporated into it (there's more than just dlls to build). > > I don't think we need to drop "deliver" to make this work. We probably do not > even have to touch any d.lst. You misunderstood me. I meant that what currently is done in "deliver" needs to be done in the build step if you omit the "delivery". Of course if you only wanted to change the process for dlls that would be trivial. But why not get rid of the local output for all "delivered" files... Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] Problem with solenv/bin/linkoo in SRC680_m235
Oliver Braun wrote: > Hi *, > > Thorsten Behrens wrote: >> Stephan Bergmann <[EMAIL PROTECTED]> writes: >>> If we want features like linkoo, first make the code ready for >>> them. (Maybe I was in a rush when I introduced osl_loadModuleRelative, >>> maybe some vnd.sun.star.expand:$WHATEVER-PREFIX scheme would be >>> better. I am very open for discussion about *that*.) >>> >> Fine with me. I'm not insisting on the current solution, only pointing >> out that triple copying around of files (local output -> solver -> >> installation tree) is a major PITA and plainly non-obvious for new >> developers. >> >> So, constructive ideas, anybody? > > What are the reasons (again) why shared libraries and dlls aren't directly > created in solver instead of the modules local output tree ? I assume mainly the fact that Hamburg developers don't have write access to solver when building non-locally. ;-) Besides I think it's just because nobody asked for it and now it's quite some work to change the build system in a way that "deliver" is incorporated into it (there's more than just dlls to build). Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Laurent Godard wrote: > Hi Mathias, Hi Martin > >>> just stumbled about that the report design extension is built during the >>> regular build process, wouldn't it be better at all to create a source >>> tarball include jfreereport and reportdesign modules. Where we already >>> achieved modularization in the sources we should IHMO also do the right >>> packaging of sources, >> >> +1! >> >> What already is separated shouldn't become munged with the rest. We know >> how fast the separation can get lost. :-) > > If an optional product, I would say yes > > But if delivered within OOo, the sources have to remain in CVS and then > the packaging is easier if all done at build process Of course they should remain in the OOo cvs. The question is: how are they built and packaged. It's a PITA to have to build the whole OOo code base and especially the "instsetoo_native" module to get a single package. As I understood it, the idea is to be able to get particular combinations of modules and build a single package from them without a lot of scp2 and instsetoo magic. OOo as a whole then will be a combination of several packages. That is the goal, not the first step. Now we are discussing what can bring us near to that goal and what might hold us back. > The report design extension is a typical example of what i called a > promoted popular extension > An extension, first has his own life outside OOo > When popular and included in OOo by default, sources come into the CVS > and is built during the whole process The point is that people want to get rid of the "whole process". That doesn't mean that we won't be able to build everything in one step but that shouldn't be the only way to build something that is part of the OOo code base. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Hi Kendy, Jan Holesovsky wrote: > Hi Mathias, > > On Friday 12 October 2007 20:18, Mathias Bauer wrote: > >> > just stumbled about that the report design extension is built during the >> > regular build process, wouldn't it be better at all to create a source >> > tarball include jfreereport and reportdesign modules. Where we already >> > achieved modularization in the sources we should IHMO also do the right >> > packaging of sources, >> >> +1! >> >> What already is separated shouldn't become munged with the rest. We know >> how fast the separation can get lost. :-) > > I am a bit confused here - I thought that jfreereport was not JCA covered > [though LGPL], so bundling it together was not what would you want on the > source level? So let me try to remove the confusion. jfreereport is LGPL without a JCA, yes. So reportdesign is derived work that is distributed as an extension. As the latter is our own code and it is OOo code we committed it to the OOo source code repository and (for convenience reasons) build it together with the "core" code base. As we are currently talking about splitting up the source I think it makes most sense to have separate builds for each extension. So there would be a package/tarball containing the jfreereport binaries and the reportdesign sources. At least that's as I understood Martin and thus my "+1". If he was aiming for something else of course that would turn into a "-1". But I hope that I understood him right. > Either way, from my point of view it is plain 3rd party stuff, so I'd like to > let it in ooo-libs-3rdparty. To avoid reportdesign intergrowth with Base, > maybe ooo-apps-extensions would be the better option for reportdesign, what > do you think? I think 3rd party stuff used in extensions should be separated from 3rd party stuff used for the "core" code base. I would even like to keep java libs separated from C(++) libs. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Jan Holesovsky wrote: > Hi Martin, > > On Monday 15 October 2007 14:11, Martin Hollmichel wrote: > >> > But for the Win32 builders, searching for the dependencies >> > could be too expensive - that's why I propose the 'super-source-package' >> > ;-) Of course, we can go the way of ooo-3rdparty-dictionaries, >> > ooo-3rdparty-epm, ooo-3rdparty-hsqldb, etc. but I'm not sure if it helps >> > in the end... >> >> this was what I was thinking about, just redistributing the 3rdparty >> packages as single one to achive maximum modularity at that level. > > But the maximum modularity is achieved if the developers use the versions > from > their distros. I understand ooo-libs-3rdparty as a fallback for the > developers that don't want to install the pieces; the ./configure would > detect if there are 'system' versions of this or that, and build just the > pieces that are not there. The advantage of one single "3rdparty" package is that you either can use it as a "make yourself happy with one click" package or you don't use it at all and use each library as part of the already available 3rd party packages that can be installed separately. Problem is that we can't cope with permanently updating OOo to the "latest and greatest" versions of these libraries and so it must be possible to install older versions of them at times. In case that isn't possible individual "oo3rdparty" packages for each single 3rd party library might come in handy. Are there any other advantages or disadvantages of either concept that I forgot to mention here? Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Jan Holesovsky schrieb: > Oh, sure! My original mail contains my suggestion of what belongs where - > please have a look, input is most appreciated. I did few corrections > afterwards (accessibility, bean, crashrep, and package moved to > ooo-apps-extensions, jut moved to ure, rvpapi removed, it's not used any > more). Yes, I already planned to have a look. I wish the day had more than 24 hours ... Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] Re: [council-esc] Is someone still building OOo with tcsh?
Volker Quetschke schrieb: > As I wrote in my earlier response, no, the support effort in *not* > significant. That is not the reason to drop the support, but testing > (RE and QA) suffer when different build environments/tools are used. Isn't that a significant effort? :-) Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Martin Hollmichel schrieb: > Hi, > > just stumbled about that the report design extension is built during the > regular build process, wouldn't it be better at all to create a source > tarball include jfreereport and reportdesign modules. Where we already > achieved modularization in the sources we should IHMO also do the right > packaging of sources, +1! What already is separated shouldn't become munged with the rest. We know how fast the separation can get lost. :-) Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Rüdiger Timm schrieb: > I am not against having the possibility to get smaller, logically > connected parts of the code base separately. What I do not want (and > perhaps that was a misinterpretation of the original posting) is having > different parts in different, distinct archives. Of course. As I understand it, the idea is to get more and better defined packages and the ability to rebuild only parts of them. Whether the code to build the packages comes from a single repository or not doesn't make a difference, so keeping one repository obviously is fine. But it should be possible to download only parts of the whole OOo source and build only the parts you want. > My feeling is we should first do some work on our code base so that be > really can benefit from a split. Absolutely. There are a few modules where we don't need this but over all the code base will be the limiting factor. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Rüdiger Timm wrote: > Personally, I do not like spitting up sources at all. But that's my very > personal opinion. Splitting up source definitely is a good idea. Maybe not for people building everything anyway but it would be a huge step ahead for the casual developer like volunteers, distro maintainers etc. And no, Solver tarballs are not a replacement for this, they are yet another workaround as I have learned when I had an email conversation with Petr. So I definitely second the approach to split the source. The problem is - as I reported in my presentation in Barcelona - that we have to rework some libraries and even sources to move that forward and to effectively gain anything from this. Currently we can achieve only a small benefit but as always a large journey starts with the first step. > Besides this, I do not understand how your proposal could work (see > above). So I would propose existing and well tested means to achieve > nearly the same goals. F.e., the build tool provides a possibility to > build distributed on several computers. You always refer to your "always build everything" approach. There's more than this. Having a huge monolithic project structure and workarounding this by providing tools to tame the beast is better than nothing but perhaps it's time to improve. The result will not make a big difference for the "always everything" people but it will help others. So once reasonable packages have been defined we can think about splitting the source also. The first preparations have been done (URE split) or are under work (sdf split as you mentioned yourself). I think there are a lot of reasonale packages that can be identified right now where building them separately will work. I opt for helpcontent, binfilter and all the applications. And the next goal should be getting updated packages by just building the source packages needed, not by always building full installation sets. Can you imagine what a relief it would be not to build and pack everything because you already have the binaries in your OOo installation and only rebuild the Calc package because you only wanted to fix a small bug in Calc? Of course to be able to gain something from this we also need "development packages" for the OOo packages. So there's something to do, but why not start? Of course I take it for granted that those suggesting the change will help doing it. ;-) Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] ccache for MSVC
Eike Rathke wrote: > Hi Mathias, > > On Thursday, 2007-07-05 11:55:49 +0200, Mathias Bauer wrote: > >> I've set $CXX and $CCACHE_DIR as described and copied the ccache.exe I >> downloaded from your site into $CCACHE_DIR. >> >> On VC2003 I got >> >> "Execvp error. Aborting.: No such file or directory" > > That seems to be a misunderstanding. The ccache.exe of course should > reside in a directory that's reachable via PATH, the CCACHE_DIR variable > points to the directory where ccache puts its cache files. It should be > on a fast disk local to the machine you're compiling on. See also > http://man.cx/ccache Thanks, works with VC2003 now. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] ccache for MSVC
Jan Holesovsky wrote: > Hi, > > For those building on Win32, it might be interesting that I've extended the > ccache [http://ccache.samba.org/] to deal with MSVC. I've done it during our > Novell HackWeek [http://idea.opensuse.org]; I hope you'll enjoy it as much as > I enjoyed the hacking on that ;-) > > It is easy to use, instead of 'guw.exe cl.exe', you'll use 'guw.exe ccache.exe > cl.exe' in your CXX environment variable after having sourced the > environment. To see the ccache statistic, use ccache -s. You can override > the directory where is the cache stored by exporting CCACHE_DIR="c: > \where\you\want" Should you find any bugs, please send me patches :-) I don't have a patch ;-) but I wanted to report that I couldn't get it to work, neither with MSVC2003 nor with MSVC2005 Express. I've set $CXX and $CCACHE_DIR as described and copied the ccache.exe I downloaded from your site into $CCACHE_DIR. On VC2003 I got "Execvp error. Aborting.: No such file or directory" and on VC2005 it was something pointing out that the compiler couldn't be detected. Is something missing in your description? Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
