Building OpenOffice revisited (again)
I would like to present some ideas about how to improve the building of OpenOffice. Maybe this can serve as a basis for a face-to-face discussion at FOSDEM. Makefiles in general and our build environment in particular have a declarative and an imperative part. In short dependencies are declared and build recipes are given as instructions. This is reflected by both our build systems. For dmake we have makefile.mk files in all source directories. They contain basically the names of libraries to build and c++ files to compile. The recipes that define how to link and compile are located in solenv/inc/. This is similar for gbuild. There are a couple of makefiles (named Makefile, Module...mk, Library...mk and so on) in the top level module directories. They also just declare the set of files to compile or link. The gbuild recipes can be found in solenv/gbuild/. This observation together with my (our) unhappiness of the current state of our build systems lead me to the following insight. One obstacle when playing around with other build tools, like cmake or ninja or just plain GNU make makefiles (as opposed to our meta-programming gbuild files) is the syntax of how our dependencies are declared. It would be so much easier when they would be stored in a file format that is both machine and human readable and not tied to one specific program. What if we used XML files to represent the dependencies? We could convert the gbuild makefiles into XML files with very similar structure. A simple Perl script or Java program (both understand XML and are part of our build prerequisites) can convert the XML file to gbuild files that would be almost identical to what we have today. And when we want to try alternatives, we can provide other converters and make experiments. See [2] for an example. Such a converter could be more complex than just do a simple syntax translation. For using ninja [1], which is described as assembler and has no %.o : %c rules and no if/else/fi, we would need more than that. But still less than cmake because our compiler (and other build tool) detection is done by configure. Using XML files would probably not much of an overhead. The translation into makefiles has to be done only when the makefile/XML representation changes. The additional dependencies, one per current makefile (less than 10 in the average module), are negligible compare to the dependencies for several hundreds of source files and several thousands of headers. But again, this is not (yet) a proposal for change. Just the basis for discussion. It is also not (yet) a non-proposal for changing the build system completely. Just the idea to express our business logic in a way that is independent from the build system (whichever we use/will use). Best regards, Andre [1] http://martine.github.io/ninja/manual.html [2] Excerpt from sw/Library_sw.mk: $(eval $(call gb_Library_add_linked_libs,sw,\ avmedia \ basegfx \ comphelper \ ... vcl \ vos3 \ xo \ $(gb_STDLIBS) \ )) $(eval $(call gb_Library_add_exception_objects,sw,\ sw/source/core/SwNumberTree/SwNodeNum \ sw/source/core/SwNumberTree/SwNumberTree \ sw/source/core/access/acccell \ ... sw/source/ui/wrtsh/wrtsh3 \ sw/source/ui/wrtsh/wrtsh4 \ sw/source/ui/wrtsh/wrtundo \ )) - library=sw linked-libraries library-reference name=avmedia/ library-reference name=basegfx/ library-reference name=comphelper/ ... library-reference name=vcl/ library-reference name=vos3/ library-reference name=xo/ library-reference variable=gb_STDLIBS/ /linked-libraries source-files language=c++ exception_handling=yes file name=sw/source/core/SwNumberTree/SwNodeNum.cxx/ file name=sw/source/core/SwNumberTree/SwNumberTree/ file name=sw/source/core/access/acccell/ ... file name=sw/source/ui/wrtsh/wrtsh3/ file name=sw/source/ui/wrtsh/wrtsh4/ file name=sw/source/ui/wrtsh/wrtundo/ /source-files /library - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
update the wiki of https://wiki.openoffice.org/wiki/Uno/Cpp/Tutorials/component_tutorial
hi, I have updated the wiki of https://wiki.openoffice.org/wiki/Uno/Cpp/Tutorials/component_tutorial, if there are mistakes,you can modify it directly. thanks -- *mailto: *aoo.zhaos...@gmail.com https://google.com/profiles https://google.com/profiles
Re: config error on Windows 7
Hi, On 17.01.2014 07:52, Oliver-Rainer Wittmann wrote: Hi, On 16.01.2014 18:28, jonasalfreds...@gmail.com wrote: I got hold of a copy of Visual Studio Express 2008. With the configure call above 'oowintool' was called. The Win SDK did not add the mentioned key to the registry, nor did Visual Studio Express 2008 installer. This wonders me as I have setup a system without any Visual Studio installed. The compiler comes with the Windows SDK. This system does not have the memntioned key in the registry and the configure works. I will have a closer look into the configure. A closer look to the configure, the oowintool and also my Windows 7 registry reveals the following: The searched registry key does not exist, but registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Setup\VC exists which is somehow found by the oowintool - see sub reg_get_value($) in oowintool. I observed this situation on three Windows 7 machine (virtual ones and non-virtual ones) on which I have setup an AOO build environment. Did you found the same registry key on your system? Currently, I do not know what went wrong on your system. Best regards, Oliver. Best regards, Oliver. /Jonas -- View this message in context: http://openoffice.2283327.n4.nabble.com/config-error-on-Windows-7-tp4652383p4657930.html Sent from the Development mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Building OpenOffice revisited (again)
On 17 January 2014 09:26, Andre Fischer awf@gmail.com wrote: I would like to present some ideas about how to improve the building of OpenOffice. Maybe this can serve as a basis for a face-to-face discussion at FOSDEM. Quite a nice idea, its more or less the base we use in the capstone project. With the capstone project we try to convert the current system to a visual studio solution, which are xml. The idea being that we can easy 1) convert it to a generic xml structure 2) build a vc and makefile generator (basically just a huge style sheet) I was going to talk about it at FOSDEM, but due to some unfortunate (but logical) clashes, preferred not to. rgds jan I. Makefiles in general and our build environment in particular have a declarative and an imperative part. In short dependencies are declared and build recipes are given as instructions. This is reflected by both our build systems. For dmake we have makefile.mk files in all source directories. They contain basically the names of libraries to build and c++ files to compile. The recipes that define how to link and compile are located in solenv/inc/. This is similar for gbuild. There are a couple of makefiles (named Makefile, Module...mk, Library...mk and so on) in the top level module directories. They also just declare the set of files to compile or link. The gbuild recipes can be found in solenv/gbuild/. This observation together with my (our) unhappiness of the current state of our build systems lead me to the following insight. One obstacle when playing around with other build tools, like cmake or ninja or just plain GNU make makefiles (as opposed to our meta-programming gbuild files) is the syntax of how our dependencies are declared. It would be so much easier when they would be stored in a file format that is both machine and human readable and not tied to one specific program. What if we used XML files to represent the dependencies? We could convert the gbuild makefiles into XML files with very similar structure. A simple Perl script or Java program (both understand XML and are part of our build prerequisites) can convert the XML file to gbuild files that would be almost identical to what we have today. And when we want to try alternatives, we can provide other converters and make experiments. See [2] for an example. Such a converter could be more complex than just do a simple syntax translation. For using ninja [1], which is described as assembler and has no %.o : %c rules and no if/else/fi, we would need more than that. But still less than cmake because our compiler (and other build tool) detection is done by configure. Using XML files would probably not much of an overhead. The translation into makefiles has to be done only when the makefile/XML representation changes. The additional dependencies, one per current makefile (less than 10 in the average module), are negligible compare to the dependencies for several hundreds of source files and several thousands of headers. But again, this is not (yet) a proposal for change. Just the basis for discussion. It is also not (yet) a non-proposal for changing the build system completely. Just the idea to express our business logic in a way that is independent from the build system (whichever we use/will use). Best regards, Andre [1] http://martine.github.io/ninja/manual.html [2] Excerpt from sw/Library_sw.mk: $(eval $(call gb_Library_add_linked_libs,sw,\ avmedia \ basegfx \ comphelper \ ... vcl \ vos3 \ xo \ $(gb_STDLIBS) \ )) $(eval $(call gb_Library_add_exception_objects,sw,\ sw/source/core/SwNumberTree/SwNodeNum \ sw/source/core/SwNumberTree/SwNumberTree \ sw/source/core/access/acccell \ ... sw/source/ui/wrtsh/wrtsh3 \ sw/source/ui/wrtsh/wrtsh4 \ sw/source/ui/wrtsh/wrtundo \ )) - library=sw linked-libraries library-reference name=avmedia/ library-reference name=basegfx/ library-reference name=comphelper/ ... library-reference name=vcl/ library-reference name=vos3/ library-reference name=xo/ library-reference variable=gb_STDLIBS/ /linked-libraries source-files language=c++ exception_handling=yes file name=sw/source/core/SwNumberTree/SwNodeNum.cxx/ file name=sw/source/core/SwNumberTree/SwNumberTree/ file name=sw/source/core/access/acccell/ ... file name=sw/source/ui/wrtsh/wrtsh3/ file name=sw/source/ui/wrtsh/wrtsh4/ file name=sw/source/ui/wrtsh/wrtundo/ /source-files /library - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[Bugzilla] Proposal: Further value for field Version - namely pre 3.4.0
Hi, during the review of issues (newly submitted ones and also critical ones) I observed the following: Sometimes it reveals that the described defect already occurs in OpenOffice versions which had been released before OpenOffice found its new home at Apache. Unfortunately, the available values for field Version in our Bugzilla instance are limited to values of versions which had been released under the hood of Apache. In order to mark these kind of issues more accurate and to distinguish them from issues which had been introduced in version 3.4.0 I propose to introduce value pre 3.4.0 (or similar) for field Version in Bugzilla. From my point of view it will help - at least me - to prioritize the issues. Any objections to introduce this new value for field Version in Bugzilla? Best regards, Oliver. P.S.: Issue 123063 [1] is closely related to my proposal. [1] https://issues.apache.org/ooo/show_bug.cgi?id=123063 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Reporting a problem with the OpenOffice website
Hi Dev Problem when trying to download legacy version. So when I click download nothing happens, just go to the "Please contribute!" page. The I went to "select a mirror close to you" but when i cant download from any, just shows http or ftp or rsynce but when you click it just goes into a directory And most mirrors either don't have the files or the page doesn't exist! And the wiki and redirector both say object not found. Please assist. -- Best Regards Lex Ridley Director Arctic Howl Tel: 011 465 1033 Cell: 073 436 8033 Email: l...@arctichowl.co.za Web: www.arctichowl.co.za
AOO 4.1 Feature Verification Test needs your help -- Call for volunteers!
Hi All, We have made some progress on the 4.1 Feature Verification Test (FVT) execution with help from Edwin, Maryna and Liu Ping and will get even more done with upcoming helping from Nadya and Simon. But we still have a lot of work to do. We still have 945 testcases to run. Completing these tests is critical to finish feature FVT before February 13th, so we can start the beta for AOO 4.1 on time as scheduled [1]. We need your help. Even if you don't consider yourself a tester, you can still help. You just need to be familiar with the OpenOffice product and be able to follow test instructions and record your results. If every volunteer can do a number of executions, then we will get a great achievement. We need volunteers on Linux Redhat 64bit, Linux Redhat 32bit, Linux Ubuntu 64bit, Mac 10.8/10.9, Windows 7 and Windows 8. If you have interest and can help over the next few weeks, please send a note to the QA mailing list (q...@openoffice.apache.org). If you have a Testlink account[2] send your ID as well as what platform you can help test. You should also get installation sets from trunk [3] and report issues in Bugzilla [4]. Thanks! [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning [2] http://aootesting.adfinis-sygroup.org/index.php [3] http://ci.apache.org/projects/openoffice/ [4] https://issues.apache.org/ooo/ Yuzhen Fan(范玉珍)
Re: Issues found when testing comments/annotations on test ranges - 1st batch
Oliver, thank you for the quick response, I will verify the fix in next buildbot build. On Thu, Jan 16, 2014 at 8:11 PM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 16.01.2014 10:59, Oliver-Rainer Wittmann wrote: Hi, On 15.01.2014 14:33, Oliver-Rainer Wittmann wrote: Hi, On 15.01.2014 12:08, Yuzhen Fan wrote: I start executing test cases for the integration of OSBA OOXML improvement project's use case 4 - comments/annotations on text ranges, here is the first batch of bugs: Bug 124030 - Failed to open ODT file exported from AOO with comment/annotation in original docx file Yes, this is very critical and I will provide a patch today. The crash occurs in case there a character formatting at the annotated text range. Issue is fixed, now. The next buildbot builds will contain the fix. Best regards, Oliver. Bug 124028 - Highlight of commented/annotated text range gets lost when export as PDF by AOO Please have a look at my comment in the issue. Short version: PDF export of AOO and Microsoft Word regarding comments/annotations are not comparable. To enhance AOO's PDF for comments/annotations on text ranges further details from the PDF format are needed. Bug 124027 - The list numbers/bullets in comment/annotation get lost when import .docx file to AOO This issue is not related to the new introduced feature to apply comments/annotations on text ranges. For further details have a look at my comment to the issue. Best regards, Oliver. The first one is critical and fails all test cases. I will have a look at these issues. Best regards, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Regards, Yu Zhen
Re: Reporting a problem with the OpenOffice website
On Fri, 17 Jan 2014 11:21:49 +0200 Lex Ridley l...@arctichowl.co.za wrote: Hi Dev Problem when trying to download legacy version. So when I click download nothing happens, just go to the Please contribute! page. The I went to select a mirror close to you but when i cant download from any, just shows http or ftp or rsynce but when you click it just goes into a directory And most mirrors either don't have the files or the page doesn't exist! And the wiki and redirector both say object not found. Please assist. -- Best Regards Lex Ridley Director Arctic Howl Tel: 011 465 1033 Cell: 073 436 8033 Email: l...@arctichowl.co.za Web: www.arctichowl.co.za Which version, operating system and language do you require? If we know those we can perhaps hive you a direct link. -- Rory O'Farrell ofarr...@iol.ie - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: loadComponentFromURL - Solaris 11 OO 3.3
On 17/01/2014 00:29, Paul Gress wrote: There is one person (Apostols Syropoulos) trying to compile the latest version 4.0, but having trouble. Then there are at least 2. I've tried and so far failed to compile 4.0. [I'm using self built 3.4.1] James. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[QA][Test Report] Weekly Status Update as of 20140117
Hi All, We started doing the AOO 4.1 Function Verification test(FVT), here is the weekly update (1/13 - 1/17): *Test execution:* 1. New feature testing on comments/Annotations on text ranges - Ongoing Bugs found: (red one is critical) Bug 124030 - Failed to open ODT file exported from AOO with comment/annotation in original docx file (fix submitted by Oliver, will verify with next build) Bug 124028 - Highlight of commented/annotated text range gets lost when export as PDF by AOO Bug 124027 - The list numbers/bullets in comment/annotation get lost when import .docx file to AOO 2. Improved feature testing on In-place editing of Input Fields - Complete Bugs found: Bug 123827- [Accessibility][IA2]Focus value of Field function type list can't be identified in writer Bug 123828 - [Accessibility]Tab Key can't travel in input field dialogue in writer Bug 123825 - The content change when importing .docx with “Date field Bug 123826 - The content lost when importing .docx with “Fill-in field 3. Existing feature on 3 APP testing - Ongoing We have assigned 287 text executions to about 5 volunteers, and completed about 13.8% in execution (150 test executions done). We are far from and tight to finish feature FVT before Feb 13 with current resource. I have sent 2nd call for volunteers in community. TotalNot RunPassedFailedBlockedCompleted [%] Debian Linux 64bit5673610387.5 MacOS X20918515908.13 Redhat Linux 32bit69670202.90 Redhat Linux 64bit2222193001.35 Ubuntu Linux 64bit1671652001.20 Windows 71801253817231.67 Windows 818216911207.14 Total108593710540513.8 *Defect summary:* see above bug lists in Test execution *Issues quality highlight:* 1. We have execution gap in FVT test as lack volunteers in testing, have sent the 2nd call for volunteers 2. Build for Mac 64bit is not available in buildbot and dev snapshot 3. Build for Linux is not available in dev snapshot *Volunteer status: * 1. No new volunteers(total 5 so far) on FVT execution work, 2 person(Edwin and Liu Ping) ask for more as they have completed their assignment *Plan for next week:* 1. Continue to do FVT test on Mac, Linux and Windows 2. Continue to do testing on comments/Annotations on text ranges 3. Summarize high priority issues in Bugzilla Thanks you all for effort this week, let's continue and make progress next week! Regards, Yu Zhen
Re: Building on Windows 7
Same result when running cygwin as administrator. -- View this message in context: http://openoffice.2283327.n4.nabble.com/Building-on-Windows-7-tp4657909p4657970.html Sent from the Development mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Bugzilla] Proposal: Further value for field Version - namely pre 3.4.0
On Fri, Jan 17, 2014 at 4:34 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, during the review of issues (newly submitted ones and also critical ones) I observed the following: Sometimes it reveals that the described defect already occurs in OpenOffice versions which had been released before OpenOffice found its new home at Apache. Unfortunately, the available values for field Version in our Bugzilla instance are limited to values of versions which had been released under the hood of Apache. In order to mark these kind of issues more accurate and to distinguish them from issues which had been introduced in version 3.4.0 I propose to introduce value pre 3.4.0 (or similar) for field Version in Bugzilla. From my point of view it will help - at least me - to prioritize the issues. Any objections to introduce this new value for field Version in Bugzilla? The thing we're trying to avoid, I think, is someone reporting an issue in an older version of OOo without first upgrading and seeing whether it is already fixed in the current version of AOO. If a bug existed in, say, OOo 3.3.0 and still exists in AOO 4.0.1, it is not incorrect to label it as an AOO 4.0.1 bug. In fact this will happen quite often. We don't have the QA resources to do archeological research and re-test every new bug in older versions. So the meaning of version has been something like what version of the product did you detect the bug in with the constriction that we highly encourage the user to be running a current version of AOO before reporting any bug. This isn't a perfect solution, of course, and I have no objection to us revisiting this. But I just wanted to make sure we all knew why it is how it is today. Regards, -Rob Best regards, Oliver. P.S.: Issue 123063 [1] is closely related to my proposal. [1] https://issues.apache.org/ooo/show_bug.cgi?id=123063 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Hello to the Apache Project Team
On Wed, Jan 15, 2014 at 9:18 PM, Shari Bradstream counselingwithhor...@gmail.com wrote: Good evening, I came across the Apache Open Office software and find it intriguing. I like what I read so decided to invest a little time each week to work on project materials in the areas that help is needed. I am not a computer programmer or coder, however; I am very creative and able to navigate my way through directions and can think outside the box. I am a licensed professional counselor and a certified addictions therapist in South Dakota at a non-profit company I started. I am working with high risk offenders, vulnerable populations in a culturally diverse office setting, and best of all using Equine Assisted Learning in all my individual and group settings. I look forward to being a part of a creative team invested in providing a service to others - especially in the computer technology arena. Hello Shari, Thank for writing and volunteering to help. You can read more about different areas of the project here: http://openoffice.apache.org/get-involved.html As you will see, it takes a lot more than just programmers to make Apache OpenOffice successful. Volunteers are welcome in any of these areas. We're currently in the testing phase for our 4.1 release. If that interests you at all, we certainly need help there. You can write to our QA mailing list at q...@openoffice.apache.org to get started there. We also have new volunteer orientation modules on the website that give more background on the project and how it works. It also describes to get involved in areas like documentation, marketing, etc.: http://openoffice.apache.org/orientation/index.html Let me know if you any questions getting started. Regards, -Rob, Apache OpenOffice Project Management Committee My best regards, Shari Bradstream Shari L. Bradstream MS, LAC, LPC Director, HorsePlay Productions Hlg. Ctr. 22800 Spruce Drive Box Elder, SD 57719 Phone: 605-393- Do what is right...even if it is hard. ~ Anonymous This message is intended only for the use of the individuals or entity to which it is addresses and may contain information that is privileged, confidential or exempt from disclosure under applicable federal or state law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, please immediately notify the sender and destroy or return all copies of this email and all attachments. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Introduction-Isaak Nate
On Wed, Jan 15, 2014 at 11:58 PM, Ike Nate iken...@gmail.com wrote: Hello Apache OpenOffice Team, I would like to introduce myself. My name is Isaak Natenzon and I am from New York, I found this e-mail through uTest, where I am a SQA Tester. I am familiar with OpenOffice because I have used it in the past. I got certified MCSE and CCNA back in 2000. I worked as a network admin for Fleet Securities/ Quick and Reilly located at 14 Wall Street, New York. After a period of time I got bored with this field, I found that it was not exciting and innovative as I imagined and coincidentally was invited to a business venture in a totally different industry. I was out of the IT field for a while, however, I tried to stay up to date with technology, and every opportunity that came up working with technology for family and friends, I was there to volunteer. Recently I was introduced by a friend to SQA Testing, watched a few James Bach seminars and I was hooked. I am interested in getting into the SQA Testing seriously and would like to contribute to OpenOffice development, and build SQA experience. Hello Isaak, Thanks for writing. This is perfect timing. We're getting started now on the first Functional Verification Test (FVT) pass for Apache OpenOffice 4.1. Once it completes FVT, and if there are no blocking defects, we'll issue a beta release, later in February. The last report I saw said the test pass was 13% complete or so, with 900 test cases remaining to be tested. We have volunteers working on Windows, Mac and Linux. You should send a note to our QA mailing list (q...@openoffice.apache.org) and let them know what platforms you can work with. Some background for new QA volunteers is here: http://openoffice.apache.org/orientation/intro-qa.html Much of that will be review since you are already familiar with SQA in general, but it will guide you to get signed up for the QA mailing list and Testlink and Bugzilla accounts. I look forward to seeing you on the QA mailing list! Let me know if you have any questions. Regards, -Rob P.S. Keep up the good work, and hope I can be of assistance. Regards, Isaak Natenzon - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
FOSDEM smalltalk.
hi should we arrange some face to face discussions, potentially not in the dev room like andre f. I would like to discuss the build system, potentially as a forerunner to work shop. Who can/will lead a digital signing project (urgent) as more than half of the vm team is there, it might be good to discuss the future. rgds jan i
FOSDEM travel reombursement.
Hi. not too sure what the status is, but better early then never. I will give 2 speaches at FOSDEM, and would like to claim the 200,- eur reimbursement (of course only to be paid after the presentations) rgds jan i
Re: Hello to the Apache Project Team
Hi Shari, Thanks for your volunteering to help, if you are interested in 4.1 testing and would like get started to do test execution and bug confirmation/verification, or join other test activities, please let me know, thanks! On Fri, Jan 17, 2014 at 11:49 PM, Rob Weir robw...@apache.org wrote: On Wed, Jan 15, 2014 at 9:18 PM, Shari Bradstream counselingwithhor...@gmail.com wrote: Good evening, I came across the Apache Open Office software and find it intriguing. I like what I read so decided to invest a little time each week to work on project materials in the areas that help is needed. I am not a computer programmer or coder, however; I am very creative and able to navigate my way through directions and can think outside the box. I am a licensed professional counselor and a certified addictions therapist in South Dakota at a non-profit company I started. I am working with high risk offenders, vulnerable populations in a culturally diverse office setting, and best of all using Equine Assisted Learning in all my individual and group settings. I look forward to being a part of a creative team invested in providing a service to others - especially in the computer technology arena. Hello Shari, Thank for writing and volunteering to help. You can read more about different areas of the project here: http://openoffice.apache.org/get-involved.html As you will see, it takes a lot more than just programmers to make Apache OpenOffice successful. Volunteers are welcome in any of these areas. We're currently in the testing phase for our 4.1 release. If that interests you at all, we certainly need help there. You can write to our QA mailing list at q...@openoffice.apache.org to get started there. We also have new volunteer orientation modules on the website that give more background on the project and how it works. It also describes to get involved in areas like documentation, marketing, etc.: http://openoffice.apache.org/orientation/index.html Let me know if you any questions getting started. Regards, -Rob, Apache OpenOffice Project Management Committee My best regards, Shari Bradstream Shari L. Bradstream MS, LAC, LPC Director, HorsePlay Productions Hlg. Ctr. 22800 Spruce Drive Box Elder, SD 57719 Phone: 605-393- Do what is right...even if it is hard. ~ Anonymous This message is intended only for the use of the individuals or entity to which it is addresses and may contain information that is privileged, confidential or exempt from disclosure under applicable federal or state law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, please immediately notify the sender and destroy or return all copies of this email and all attachments. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Regards, Yu Zhen
Re: Building OpenOffice revisited (again)
On Fri, Jan 17, 2014 at 12:26 AM, Andre Fischer awf@gmail.com wrote: I would like to present some ideas about how to improve the building of OpenOffice. Maybe this can serve as a basis for a face-to-face discussion at FOSDEM. Makefiles in general and our build environment in particular have a declarative and an imperative part. In short dependencies are declared and build recipes are given as instructions. This is reflected by both our build systems. For dmake we have makefile.mk files in all source directories. They contain basically the names of libraries to build and c++ files to compile. The recipes that define how to link and compile are located in solenv/inc/. This is similar for gbuild. There are a couple of makefiles (named Makefile, Module...mk, Library...mk and so on) in the top level module directories. They also just declare the set of files to compile or link. The gbuild recipes can be found in solenv/gbuild/. This observation together with my (our) unhappiness of the current state of our build systems lead me to the following insight. One obstacle when playing around with other build tools, like cmake or ninja or just plain GNU make makefiles (as opposed to our meta-programming gbuild files) is the syntax of how our dependencies are declared. It would be so much easier when they would be stored in a file format that is both machine and human readable and not tied to one specific program. What if we used XML files to represent the dependencies? We could convert the gbuild makefiles into XML files with very similar structure. A simple Perl script or Java program (both understand XML and are part of our build prerequisites) can convert the XML file to gbuild files that would be almost identical to what we have today. And when we want to try alternatives, we can provide other converters and make experiments. See [2] for an example. Such a converter could be more complex than just do a simple syntax translation. For using ninja [1], which is described as assembler and has no %.o : %c rules and no if/else/fi, we would need more than that. But still less than cmake because our compiler (and other build tool) detection is done by configure. Using XML files would probably not much of an overhead. The translation into makefiles has to be done only when the makefile/XML representation changes. The additional dependencies, one per current makefile (less than 10 in the average module), are negligible compare to the dependencies for several hundreds of source files and several thousands of headers. But again, this is not (yet) a proposal for change. Just the basis for discussion. It is also not (yet) a non-proposal for changing the build system completely. Just the idea to express our business logic in a way that is independent from the build system (whichever we use/will use). Best regards, Andre Any move to making tracking dependencies (build setups) for the modules better/easier is a move in the right direction. We have quite an inconsistent mix right now. Look at what's in /connectivity vs /comphelper as an example. Discuss away! :) [1] http://martine.github.io/ninja/manual.html [2] Excerpt from sw/Library_sw.mk: $(eval $(call gb_Library_add_linked_libs,sw,\ avmedia \ basegfx \ comphelper \ ... vcl \ vos3 \ xo \ $(gb_STDLIBS) \ )) $(eval $(call gb_Library_add_exception_objects,sw,\ sw/source/core/SwNumberTree/SwNodeNum \ sw/source/core/SwNumberTree/SwNumberTree \ sw/source/core/access/acccell \ ... sw/source/ui/wrtsh/wrtsh3 \ sw/source/ui/wrtsh/wrtsh4 \ sw/source/ui/wrtsh/wrtundo \ )) - library=sw linked-libraries library-reference name=avmedia/ library-reference name=basegfx/ library-reference name=comphelper/ ... library-reference name=vcl/ library-reference name=vos3/ library-reference name=xo/ library-reference variable=gb_STDLIBS/ /linked-libraries source-files language=c++ exception_handling=yes file name=sw/source/core/SwNumberTree/SwNodeNum.cxx/ file name=sw/source/core/SwNumberTree/SwNumberTree/ file name=sw/source/core/access/acccell/ ... file name=sw/source/ui/wrtsh/wrtsh3/ file name=sw/source/ui/wrtsh/wrtsh4/ file name=sw/source/ui/wrtsh/wrtundo/ /source-files /library - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason
Re: [Bugzilla] Proposal: Further value for field Version - namely pre 3.4.0
Hi, On 17.01.2014 15:33, Rob Weir wrote: On Fri, Jan 17, 2014 at 4:34 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, during the review of issues (newly submitted ones and also critical ones) I observed the following: Sometimes it reveals that the described defect already occurs in OpenOffice versions which had been released before OpenOffice found its new home at Apache. Unfortunately, the available values for field Version in our Bugzilla instance are limited to values of versions which had been released under the hood of Apache. In order to mark these kind of issues more accurate and to distinguish them from issues which had been introduced in version 3.4.0 I propose to introduce value pre 3.4.0 (or similar) for field Version in Bugzilla. From my point of view it will help - at least me - to prioritize the issues. Any objections to introduce this new value for field Version in Bugzilla? The thing we're trying to avoid, I think, is someone reporting an issue in an older version of OOo without first upgrading and seeing whether it is already fixed in the current version of AOO. If a bug existed in, say, OOo 3.3.0 and still exists in AOO 4.0.1, it is not incorrect to label it as an AOO 4.0.1 bug. In fact this will happen quite often. We don't have the QA resources to do archeological research and re-test every new bug in older versions. So the meaning of version has been something like what version of the product did you detect the bug in with the constriction that we highly encourage the user to be running a current version of AOO before reporting any bug. This isn't a perfect solution, of course, and I have no objection to us revisiting this. But I just wanted to make sure we all knew why it is how it is today. I can follow the arguments and I do not want to propose that every reported issue should be checked in an older version. But since OpenOffice found its new home at Apache we had changes at some more basics - e.g. exchange of the neon library by the serf library, more updates to 3rd party libraries, kick of Mozilla libs, introduction of 3rd party library CoinMP, kick of STLport, introduction of the Sidebar, introduction of IA2, removal of the 3-layer office, ... These changes might cause by side effects issues whose relation is not directly seen. Thus, I personally draw more attention to issues which had been introduced by 3.4.0 and later than to issues introduced by pre 3.4.0 versions. Thus, when an issue comes to my focus in an area which I know and I am not aware of a corresponding change in this area since 3.3.0 which could have triggered this issue I have a former OOo version at hand - OOo 3.2.0 and OOo 3.3.0 and also OOo 3.4 Beta. Thus, just a quick check of the issue in these versions allows me to prioritize it. Important is to keep this information searchable in Bugzilla. Thus, I would like to tag issues which occurs in pre 3.4.0 version appropriately and to filter these issues with corresponding Bugzilla queries. Best regards, Oliver Regards, -Rob Best regards, Oliver. P.S.: Issue 123063 [1] is closely related to my proposal. [1] https://issues.apache.org/ooo/show_bug.cgi?id=123063 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Bugzilla] Proposal: Further value for field Version - namely pre 3.4.0
Oliver-Rainer Wittmann wrote: I would like to tag issues which occurs in pre 3.4.0 version appropriately This would be helpful for me too. Probably two new categories: - 3.3.0 or earlier - 3.4.0-beta This would allow to file all bugs appropriately. The latter category would be useful only for QA purposes, I believe 3.4.0-beta does not have a significant number of users. We have the version field for (in theory) the first version containing the bug (in practice, most people set it to the version where they observed the bug). Then we have the Latest confirmation on field to check whether the bug still applies to the latest release. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
