Re: Automated gbuild -> SCons convertibility now at 88.57%
Awesome Damjan, I had a talk with SCons on freenode IRC. they liked the plan to move to SCons a lot. And did support us right a way. :) So I am poretty confidant that SCons will do the trick. How did you talk to SCon people? I think there is are some more tools that we need to examine before we can drop Cygwin. http://www.openoffice.org/tools/build_env_tools.html I have to look at the SCons. I plan to build GSICheck also with SCons, even if it is a total simple tool. All the best. Peter Am 04.07.20 um 20:44 schrieb Damjan Jovanovic: Hi In the scons-build branch, I've just pushed a set of 11 commits that theoretically get 93 out of 105 gbuild modules (88.57%) automatically converting to gbuild. The "gotoSCons" converter and the SCons infrastructure in that branch have now been developed to such a level that a module can be automatically converted from gbuild to SCons, from where it can use SCons for all of the following: Building C/C++ objects Linking shared libraries, static libraries, and executables Building JUnit tests and running them Building Google Tests and running them Building .component files with XSLT Running Ant sub-builds Delivering "package" files such as headers Even doing the impossibly difficult 5 step "AllLangResTarget" (.src -> merged .src -> .srs -> .res for each language). I still have to implement Jar, Zip, UnoApi, WinResTarget and SdiTarget, but I think only Jar and Zip are worth implementing automatic conversion for, as SdiTarget and UnoApi are only used in 5 places each, and WinResTarget in only 2 places, which makes manual conversion for them easier. The hardest conversions are already done. Where does this leave us? The gotoSCons converter can't support a number of features, like non-deterministic constructs (ifeq ($(GUI),UNX)), custom make rules, etc. A module can only be automatically converted if it doesn't use the unsupported features. Currently, 35 modules use only supported features, and can be converted automatically (this should increase to 39 modules when I add Jar and Zip conversion). Another 58 modules use non-deterministic constructs or custom make rules. Converting those 58 could be done through a semi-automated process, which involves editing the gbuild files to remove the unsupported features, running the automated conversion on what is left, then manually patching what was removed into the conversion results. Sometimes this is quick and easy, at other times probably not. The final 12 modules use unsupported targets requiring a longer and mostly manual conversion to SCons, though even there the supported targets could be converted automatically. The SCons infrastructure does require some cleanup, as I was learning while developing, and we still need library naming conversions, tests on Linux/WIndows/Mac, etc. The more I've used SCons, the more I've liked it. I've even started using it in my own projects at work now. I've found a way to solve every problem I've encountered, and the SCons developers have been helpful when I asked them questions. Complex functionality like header dependency scanning, automatic directory creation for output files, using @responsefile for long command lines when necessary, and other features gbuild implements manually, all work in SCons automatically. In 1816 lines of code, our SCons infrastructure implements what took gbuild 9418 lines, and SCons is far more readable and maintainable (even in its current messy state). The plan isn't to merge this to trunk any time soon. Rather the idea is to develop the converter even further, then when it's complete enough, convert as many gbuild modules to SCons. Then measure performance of building those modules en-masse with SCons alone - if there are performance problems at that stage, they are only going to get worse with more modules. The real test however is converting the other 78 dmake modules to SCons. 37 of them are 3rd party "externals" like jpeg and zlib, which have their own build systems that we just call, so conversion is relatively easy. The other 41 modules are hard to convert, but gbuild is one of the reasons that they were hard, and where SCons is expected to make the greatest difference. Only once we are building without dmake, without gbuild, without build.pl, without Cygwin, on all platforms, then it would be the right time to merge to trunk. If at some stage in this process we are unhappy with SCons, and some better build system can be found, it shouldn't be difficult to change to it. The converter could output files for that other build system instead; at present it's only 498 lines of code in 1 file, that are involved in writing SCons build files, all we would need is a similar file for that other build system. Build systems are not the most exciting part of development, but bad build systems make development painful, and as a large multi-platform project, we build a lot. We answer build-related questions on the mailing lists too often,
Windows Debugging notes on the Wiki
Just found this on the wiki. https://wiki.openoffice.org/wiki/Windows_Debugging Why do I find only the stuff if I am looking for something else ... Still HTH Peter - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: 32bits-64bits après migration MacOs Catalina
Je suis désolé que mon français soit horrible. Vous devez lire les notes de mise à jour (en français) : https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=130028674 Am 05.07.20 um 03:06 schrieb B. Ruth Deerfield: Apple ne sait rien d'Open Office. J'ai dû lutter seul avec ces problèmes. Non seulement cela, j'ai un diplôme en chimie et un diplôme en médecine. je ne connais rien aux ordinateurs. ism totalement handicapé et alité ainsi. Il est donc impossible d'obtenir de l'aide d'Apple. Avez-vous des suggestions pour quelqu'un dont la langue maternelle est l'anglais? Sent from my iPhone On Jul 4, 2020, at 5:38 PM, B. Ruth Deerfield wrote: Alors, que dois-je faire avec tous mes documents des dix dernières années? Sont-ils totalement irrécupérables? J'ai 500 pages de mes mémoires et trois livres partiellement écrits. Sent from my iPhone On May 29, 2020, at 6:32 AM, Pedro Lino wrote: Cher Olivier J’ai contacté Apple, il semble que mon ordi, suite à la dernière mise à jour est passé de 32bits à 64bits. De fait le logiciel Open Office installé n’est plus compatible. Pouvez vous m’aider à installer la version Open Office compatible sans perdre tous les documents créés précédemment ? Il n'y a aucun risque pour vôtres documents. Il faut seulement faire une mise à jour do logiciel OpenOffice à la version 4.1.7 64bits https://sourceforge.net/projects/openofficeorg.mirror/files/4.1.7/binaries/fr/Apache_OpenOffice_4.1.7_MacOS_x86-64_install_fr.dmg/download Si vous avez plusieurs de questions, envoyez les seulement pour users...@openoffice.apache.org mailto:users...@openoffice.apache.org ou a mon e-mail personnel (Le français est ma langue tertiaire alors je m'excuse pour les erreurs) Cordialement. Pedro - 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
คำเตือน: ดู "โปรแกรมไม่ใช้ Google Analytics (โดย Google) " สำหรับ Chrome
คุณ (หรือคนน่าไม่อายที่สวมรอยเป็นคุณ) ส่งการแจ้งเตือนให้ดู "โปรแกรมไม่ใช้ Google Analytics (โดย Google) " สำหรับ Chrome: https://chrome.google.com/webstore/detail/google-analytics-opt-out/fllaojicojecljbmefodhfapmkghcbnh ขอแสดงความนับถือ Chrome เว็บสโตร์ ส่งจาก iPhone X
Re: Trying to re-generate the Documentation effort
Hi Carl see comments in-line On 7/4/2020 5:32 PM, Carl Marcum wrote: > Hi Keith, > > On 7/2/20 11:18 AM, Keith N. McKenna wrote: >> On 5/30/2020 8:41 PM, Keith N. McKenna wrote: >>> I should probably have my head examined but I am thinking of one more >>> time trying to revive the documentation effort for AOO. One of the >>> drawbacks is that most people that have started to help have left as >>> there has been very limited availability of mentoring. I do not see this >>> changing but I am hoping that by defining a new process we can reduce >>> the dependency on mentoring. >>> >>> One idea for this would require that the MediaWiki extension be made >>> functional again. This would allow for using Writer to create the source >>> which could be stored in the git repository and then be transferred to >>> the mwiki for easy online access. By storing the source in the >>> repository it would give us better revision control over the >>> documentation. Plus it may help relieve the mentoring problem as many >>> more people are familiar with using Writer. >>> >>> Another would be to use Docbook, though this is not as appealing as I >>> have no familiarity with it and it appears that there is a steep >>> learning curve to its use and that would be a disadvantage to attracting >>> new people. >>> >>> I look forward to any other suggestions that could move this effort >>> along as it has languished for far to long. >>> >>> Regards >>> Keith >>> >> Greetings All; >> >> I unfortunately have no good news to report at this time. It is over 2 >> weeks since I posted the Proposal document to doc@ and there has been >> zero response from the list except a couple from Detlef and Francis. I >> will send out another reminder today and wait another week to see if any >> responses come from that. >> >> Regards >> Keith > > Forgive me but I'm not any expert on documentation or technical writing > but I'll offer my opinion. Feel free to offer because truth to tell neither am I. As a Process Engineer I have written, contributed too, and edited technical documents, mostly Standards for my former employers and process documents for building finished modules from raw printed circuit boards (PCB). > > I like markup formats for the ease of source control and revision > tracking. I don't think binary files work well in this context. > I'm not real familiar with Docbook but it appears to be an XML format > which isn't all that readable on it's own but I also haven't > investigated any editors as I'm sure there are some. My preference if at all possible is to use ODF files,mostly writer.odt files, as the source documents. The product we are producing is an Office Suite so what better way to create the source documentation with the product and use that as marketing feature. The use DocBook would be limited to a small number of individuals to create other alternative delivery formats such as EPUB e-books. > > My experience with online editing like our MWiki hasn't always been > great due to time-outs for example. MWiki is not my favorite way to write documentation, but it is a good way to present it online and OpenOffice.org did it and the beginnings of the AOO documentation effort the decision was to go the MWiki route and to actually write the documentation there a decision I believe was not a good one and has turned out that way as the major driver behind it left the project and we have had a difficult time recruiting people to the effort. > > Lately I've been using AsciiDoc format and an editor called AsciiDocFX > (because it uses JavaFX for the UI) and I work right out of my project > source's local repo. > I looked at AsciiDoc and Markdown when I first started researching alternatives, and decided against them as my initial preference was to use AOO to create the source, but they could be used if using Writer does not pan out. > I'm not sure what our arrangement is with GitHub but my understanding is > that accounts get 1 github.io site and projects get unlimited pages > which are html. > I have started playing with GitHub a little bit but aside from a little exposure to SVN and the CMS applet here, my last exposure to source control was with deccms when I worked for digital equipment corporation (dec). So far I have mixed feelings about it for .odt files. > For example on my GitHub code projects I have a docs folder that > contains the AsciiDoc text files and the HTML exports from the > AsciiDocFX editor. These files are tracked with Git along with the > project code. > > So to give you a feel for it you can see a source example [1]. > What viewing the file on GitHub looks like [2]. > and finally the rendered HTML documentation site that updates a few > seconds after a commit. [3]. > > I have attached a screenshot of the editor and an exported PDF. > > What you gain in revision control of text files you give up in document > formatting. The final output will never look as good as using something > like Writer to do
Re: 32bits-64bits après migration MacOs Catalina
Apple ne sait rien d'Open Office. J'ai dû lutter seul avec ces problèmes. Non seulement cela, j'ai un diplôme en chimie et un diplôme en médecine. je ne connais rien aux ordinateurs. ism totalement handicapé et alité ainsi. Il est donc impossible d'obtenir de l'aide d'Apple. Avez-vous des suggestions pour quelqu'un dont la langue maternelle est l'anglais? Sent from my iPhone > On Jul 4, 2020, at 5:38 PM, B. Ruth Deerfield wrote: > > Alors, que dois-je faire avec tous mes documents des dix dernières années? > Sont-ils totalement irrécupérables? J'ai 500 pages de mes mémoires et trois > livres partiellement écrits. > > Sent from my iPhone > >> On May 29, 2020, at 6:32 AM, Pedro Lino wrote: >> >> Cher Olivier >> >>> >>> >>> J’ai contacté Apple, il semble que mon ordi, suite à la dernière mise à >>> jour >>> est passé de 32bits à 64bits. >>> De fait le logiciel Open Office installé n’est plus compatible. >>> >>> Pouvez vous m’aider à installer la version Open Office compatible >>> sans perdre tous les documents créés précédemment ? >>> >> Il n'y a aucun risque pour vôtres documents. >> Il faut seulement faire une mise à jour do logiciel OpenOffice à la version >> 4.1.7 64bits >> >> https://sourceforge.net/projects/openofficeorg.mirror/files/4.1.7/binaries/fr/Apache_OpenOffice_4.1.7_MacOS_x86-64_install_fr.dmg/download >> >> Si vous avez plusieurs de questions, envoyez les seulement pour >> users...@openoffice.apache.org mailto:users...@openoffice.apache.org ou a >> mon e-mail personnel >> >> (Le français est ma langue tertiaire alors je m'excuse pour les erreurs) >> >> Cordialement. >> Pedro - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: 32bits-64bits après migration MacOs Catalina
Alors, que dois-je faire avec tous mes documents des dix dernières années? Sont-ils totalement irrécupérables? J'ai 500 pages de mes mémoires et trois livres partiellement écrits. Sent from my iPhone > On May 29, 2020, at 6:32 AM, Pedro Lino wrote: > > Cher Olivier > >> >> >>J’ai contacté Apple, il semble que mon ordi, suite à la dernière mise à >> jour >>est passé de 32bits à 64bits. >>De fait le logiciel Open Office installé n’est plus compatible. >> >>Pouvez vous m’aider à installer la version Open Office compatible >>sans perdre tous les documents créés précédemment ? >> > Il n'y a aucun risque pour vôtres documents. > Il faut seulement faire une mise à jour do logiciel OpenOffice à la version > 4.1.7 64bits > > https://sourceforge.net/projects/openofficeorg.mirror/files/4.1.7/binaries/fr/Apache_OpenOffice_4.1.7_MacOS_x86-64_install_fr.dmg/download > > Si vous avez plusieurs de questions, envoyez les seulement pour > users...@openoffice.apache.org mailto:users...@openoffice.apache.org ou a mon > e-mail personnel > > (Le français est ma langue tertiaire alors je m'excuse pour les erreurs) > > Cordialement. > Pedro - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Fixes for bootstrap?
Hi Matthias > On 07/04/2020 10:55 PM Matthias Seidel wrote: > Am 04.07.20 um 21:55 schrieb Pedro Lino: > > download from > > http://hci.iwr.uni-heidelberg.de/vigra-old-versions/vigra1.6.0.tar.gz > > failed (404 Not Found) > > download failed > > > > This folder no longer exists. Is this link declared somewhere in the build > > system and could be corrected? > > Fixed now, see: > > https://github.com/apache/openoffice/commit/1f9c906e3dac41500b42db556cb26ed2c78558e0 Excellent! This raises three additional questions: 1) wouldn't it make sense to update to the most recent version https://src.fedoraproject.org/lookaside/extras/vigra/vigra-1.11.0-src-clean.tar.gz/md5/e86d096099ccc8f139b6c6fff7b7557e/ (Same as situation 4 below) Could I just go into github and fix occurrences of jpeg-8d to jpeg-9d (also fixing the md5)? https://github.com/apache/openoffice/search?q=jpeg-8d_q=jpeg-8d 2) Can I approve your commit? 3) How can this be cherry picked to branch 4.2.x ? What about situations 2 and 3? Regards, Pedro > > Second situation: > > > > Many libraries are downloaded from sourceforge (which frequently has mirror > > issues). Couldn't these libraries be hosted on the AOO server? > > > > E.g. > > download from > > https://sourceforge.net/projects/dejavu/files/dejavu/2.37/dejavu-fonts-ttf-2.37.tar.bz2 > > failed (302 Found) > > download failed > > download from > > https://sourceforge.net/projects/boost/files/boost/1.55.0/boost_1_55_0.tar.bz2 > > failed (302 Found) > > etc > > > > Third situation: > > > > Downloaded modules checksums are not verified > > > > downloading dmake-4.12.tar.bz2 > > downloading to /source/openoffice/ext_sources/dmake-4.12.tar.bz2.part > > checksum not given, md5 of file is 266d817492d8259a640fad075461080e > > downloading epm-3.7.tar.gz > > downloading to /source/openoffice/ext_sources/epm-3.7.tar.gz.part > > checksum not given, md5 of file is 3ade8cfe7e59ca8e65052644fed9fca4 > > > > Can this be added? All other modules are verified > > > > Fourth situation: > > > > downloading to > > /source/openoffice/ext_sources/52654eb3b2e60c35731ea8fc87f1bd29-jpeg-8d.tar.gz.part > > MD5 checksum is OK > > > > The current version is jpegsrc.v9d.tar.gz > > > > Would it make sense to update to this version for branch 42X? version 8d is > > from Jan 2012 and 9d from Jan 2020 > > > > Thanks! > > Pedro > > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Fixes for bootstrap?
Hi Pedro, Am 04.07.20 um 21:55 schrieb Pedro Lino: > Hi all > > I have managed to compile successfully branch 4.2.X under Ubuntu 18.04 x64 > but there are some errors during download of external dependencies that maybe > someone can fix? > > First situaton: > > download from > http://hci.iwr.uni-heidelberg.de/vigra-old-versions/vigra1.6.0.tar.gz failed > (404 Not Found) > download failed > > This folder no longer exists. Is this link declared somewhere in the build > system and could be corrected? Fixed now, see: https://github.com/apache/openoffice/commit/1f9c906e3dac41500b42db556cb26ed2c78558e0 Regards, Matthias > > Second situation: > > Many libraries are downloaded from sourceforge (which frequently has mirror > issues). Couldn't these libraries be hosted on the AOO server? > > E.g. > download from > https://sourceforge.net/projects/dejavu/files/dejavu/2.37/dejavu-fonts-ttf-2.37.tar.bz2 > failed (302 Found) > download failed > download from > https://sourceforge.net/projects/boost/files/boost/1.55.0/boost_1_55_0.tar.bz2 > failed (302 Found) > etc > > Third situation: > > Downloaded modules checksums are not verified > > downloading dmake-4.12.tar.bz2 > downloading to /source/openoffice/ext_sources/dmake-4.12.tar.bz2.part > checksum not given, md5 of file is 266d817492d8259a640fad075461080e > downloading epm-3.7.tar.gz > downloading to /source/openoffice/ext_sources/epm-3.7.tar.gz.part > checksum not given, md5 of file is 3ade8cfe7e59ca8e65052644fed9fca4 > > Can this be added? All other modules are verified > > Fourth situation: > > downloading to > /source/openoffice/ext_sources/52654eb3b2e60c35731ea8fc87f1bd29-jpeg-8d.tar.gz.part > MD5 checksum is OK > > The current version is jpegsrc.v9d.tar.gz > > Would it make sense to update to this version for branch 42X? version 8d is > from Jan 2012 and 9d from Jan 2020 > > Thanks! > Pedro > smime.p7s Description: S/MIME Cryptographic Signature
Re: should we conduct a 20 year anniversary online conference / meetup?
Hi Carl, Am 04.07.20 um 18:16 schrieb Carl Marcum: > > Hi Matthias, > > On 7/4/20 11:32 AM, Matthias Seidel wrote: >> Hi all, >> >> Bumping up this one again... >> >> Additionally, we have a virtual ApacheCon this year: >> https://apachecon.com/acna2020/ >> What about some talks about our project? >> >> Regards, >> >> Matthias > > I would definitely attend an online meetup unless the time of day was > in the middle of my night or something. We should be able to find a time frame (on a weekend) that is suitable for all timezones. > I was planning to attend ApacheCon now that is virtual. I will definitely try to follow as much content as possible. > > Doing presentations is definitely not my strongest ability but I have > a topic I've been thinking about putting a presentation together for. > > I'm finishing up the documentation before I announce it on dev@ but > I've finished an new extension to add Apache Groovy to AOO as a macro > language and another extension that recreates most of the built-in > macro examples in Groovy. > The third project is the Groovy UNO project that I've updated after a > long while. > > These are more AOO ecosystem and developer tool topics than directly > project related so I'm not sure. Sounds great! Indeed, it is very specific for AOO so maybe it fits better for our own meeting? Regards, Matthias > > Best regards, > Carl > >> >> Am 06.06.20 um 10:49 schrieb Matthias Seidel: >>> Hi, >>> >>> Am 05.06.20 um 22:41 schrieb Peter Kovacs: Hello all, This year is Anniversary year. OpenOffice becomes 20, and we will be 9 Years TLP. So Mechtilde, Matthias and I thought maybe we should do some online conference. We thought maybe on Saturday the 17.10.2020. >>> I would like to have the release of AOO 4.1.8 around that time. What >>> about a customized "About" graphic like this? [1] >>> >>> Given our "speed" let's start early! Maybe we can put the Release >>> Schedule for 4.1.8 online as a draft? [2] >>> >>> Regards, >>> >>> Matthias >>> >>> [1] https://home.apache.org/~mseidel/about_20yrs.png >>> [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Releases >>> Is there interest? What about the date? What could we do on the date? - Some discussion, meetup? plannings for the years to come? Who would attend? All the best Peter - 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 > smime.p7s Description: S/MIME Cryptographic Signature
Re: Trying to re-generate the Documentation effort
Hi Keith, On 7/2/20 11:18 AM, Keith N. McKenna wrote: On 5/30/2020 8:41 PM, Keith N. McKenna wrote: I should probably have my head examined but I am thinking of one more time trying to revive the documentation effort for AOO. One of the drawbacks is that most people that have started to help have left as there has been very limited availability of mentoring. I do not see this changing but I am hoping that by defining a new process we can reduce the dependency on mentoring. One idea for this would require that the MediaWiki extension be made functional again. This would allow for using Writer to create the source which could be stored in the git repository and then be transferred to the mwiki for easy online access. By storing the source in the repository it would give us better revision control over the documentation. Plus it may help relieve the mentoring problem as many more people are familiar with using Writer. Another would be to use Docbook, though this is not as appealing as I have no familiarity with it and it appears that there is a steep learning curve to its use and that would be a disadvantage to attracting new people. I look forward to any other suggestions that could move this effort along as it has languished for far to long. Regards Keith Greetings All; I unfortunately have no good news to report at this time. It is over 2 weeks since I posted the Proposal document to doc@ and there has been zero response from the list except a couple from Detlef and Francis. I will send out another reminder today and wait another week to see if any responses come from that. Regards Keith Forgive me but I'm not any expert on documentation or technical writing but I'll offer my opinion. I like markup formats for the ease of source control and revision tracking. I don't think binary files work well in this context. I'm not real familiar with Docbook but it appears to be an XML format which isn't all that readable on it's own but I also haven't investigated any editors as I'm sure there are some. My experience with online editing like our MWiki hasn't always been great due to time-outs for example. Lately I've been using AsciiDoc format and an editor called AsciiDocFX (because it uses JavaFX for the UI) and I work right out of my project source's local repo. I'm not sure what our arrangement is with GitHub but my understanding is that accounts get 1 github.io site and projects get unlimited pages which are html. For example on my GitHub code projects I have a docs folder that contains the AsciiDoc text files and the HTML exports from the AsciiDocFX editor. These files are tracked with Git along with the project code. So to give you a feel for it you can see a source example [1]. What viewing the file on GitHub looks like [2]. and finally the rendered HTML documentation site that updates a few seconds after a commit. [3]. I have attached a screenshot of the editor and an exported PDF. What you gain in revision control of text files you give up in document formatting. The final output will never look as good as using something like Writer to do it all in so it's a trade off. As a developer I'm comfortable using tools like Git for changes but I don't know how most tech writers feel about it. Unfortunately we also have hundreds of Dev Guide pages on the MWiki that can't be viewed right now until someone can fix the MWiki extension for some markup tags we use to write hyperlinks to the API's. So I think the less we depend on custom extensions the better. There seem to be a few markup converters like Pandoc that could help if we get stuck somewhere. [1] https://raw.githubusercontent.com/cbmarcum/guno-extension/master/docs/index.adoc [2] https://github.com/cbmarcum/guno-extension/blob/master/docs/index.adoc [3] https://cbmarcum.github.io/guno-extension/ Best regards, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Automated gbuild -> SCons convertibility now at 88.57%
On 7/4/2020 12:53 PM, Damjan Jovanovic wrote: scripting is a dmake module with no symbols package is a gbuild module with symbols So yes, as we move off dmake, more and more modules should have working debug symbols. I have suddenly become a convert to moving off dmake. This is the case on *nix too, where dmake doesn't provide full paths to filenames, breaking debugging. On Sat, Jul 4, 2020 at 9:35 PM Patricia Shanahan wrote: On 7/4/2020 12:24 PM, Damjan Jovanovic wrote: Given how I've only developed on FreeBSD so far, anything Windows is probably at negative infinity :) > Do you have some example modules with that symbols problem, or at least know whether they are gbuild or dmake modules? c:\OpenOfficeDev\openoffice\main\scripting\source\protocolhandler\scripthandler.cxx does not have symbols. c:\OpenOfficeDev\openoffice\main\package\source\xstor\xstorage.cxx does have symbols generated. On Sat, Jul 4, 2020 at 9:13 PM Patricia Shanahan wrote: In the new build system, what is the status of automatic symbol generation, needed for easy debug. It is badly broken in 4.1.7, with most modules not getting symbols generated despite --enable-symbols in the configure parameters. This has cost me weeks of work on a debug project. On 7/4/2020 11:44 AM, Damjan Jovanovic wrote: Hi In the scons-build branch, I've just pushed a set of 11 commits that theoretically get 93 out of 105 gbuild modules (88.57%) automatically converting to gbuild. The "gotoSCons" converter and the SCons infrastructure in that branch have now been developed to such a level that a module can be automatically converted from gbuild to SCons, from where it can use SCons for all of the following: Building C/C++ objects Linking shared libraries, static libraries, and executables Building JUnit tests and running them Building Google Tests and running them Building .component files with XSLT Running Ant sub-builds Delivering "package" files such as headers Even doing the impossibly difficult 5 step "AllLangResTarget" (.src -> merged .src -> .srs -> .res for each language). I still have to implement Jar, Zip, UnoApi, WinResTarget and SdiTarget, but I think only Jar and Zip are worth implementing automatic conversion for, as SdiTarget and UnoApi are only used in 5 places each, and WinResTarget in only 2 places, which makes manual conversion for them easier. The hardest conversions are already done. Where does this leave us? The gotoSCons converter can't support a number of features, like non-deterministic constructs (ifeq ($(GUI),UNX)), custom make rules, etc. A module can only be automatically converted if it doesn't use the unsupported features. Currently, 35 modules use only supported features, and can be converted automatically (this should increase to 39 modules when I add Jar and Zip conversion). Another 58 modules use non-deterministic constructs or custom make rules. Converting those 58 could be done through a semi-automated process, which involves editing the gbuild files to remove the unsupported features, running the automated conversion on what is left, then manually patching what was removed into the conversion results. Sometimes this is quick and easy, at other times probably not. The final 12 modules use unsupported targets requiring a longer and mostly manual conversion to SCons, though even there the supported targets could be converted automatically. The SCons infrastructure does require some cleanup, as I was learning while developing, and we still need library naming conversions, tests on Linux/WIndows/Mac, etc. The more I've used SCons, the more I've liked it. I've even started using it in my own projects at work now. I've found a way to solve every problem I've encountered, and the SCons developers have been helpful when I asked them questions. Complex functionality like header dependency scanning, automatic directory creation for output files, using @responsefile for long command lines when necessary, and other features gbuild implements manually, all work in SCons automatically. In 1816 lines of code, our SCons infrastructure implements what took gbuild 9418 lines, and SCons is far more readable and maintainable (even in its current messy state). The plan isn't to merge this to trunk any time soon. Rather the idea is to develop the converter even further, then when it's complete enough, convert as many gbuild modules to SCons. Then measure performance of building those modules en-masse with SCons alone - if there are performance problems at that stage, they are only going to get worse with more modules. The real test however is converting the other 78 dmake modules to SCons. 37 of them are 3rd party "externals" like jpeg and zlib, which have their own build systems that we just call, so conversion is relatively easy. The other 41 modules are hard to convert, but gbuild is one of the reasons that they were hard, and where SCons is expected
Re: Automated gbuild -> SCons convertibility now at 88.57%
scripting is a dmake module with no symbols package is a gbuild module with symbols So yes, as we move off dmake, more and more modules should have working debug symbols. This is the case on *nix too, where dmake doesn't provide full paths to filenames, breaking debugging. On Sat, Jul 4, 2020 at 9:35 PM Patricia Shanahan wrote: > On 7/4/2020 12:24 PM, Damjan Jovanovic wrote: > > Given how I've only developed on FreeBSD so far, anything Windows is > > probably at negative infinity :) > > > Do you have some example modules with that symbols problem, or at least > > know whether they are gbuild or dmake modules? > > c:\OpenOfficeDev\openoffice\main\scripting\source\protocolhandler\scripthandler.cxx > > does not have symbols. > > c:\OpenOfficeDev\openoffice\main\package\source\xstor\xstorage.cxx does > have symbols generated. > > > > On Sat, Jul 4, 2020 at 9:13 PM Patricia Shanahan wrote: > > > >> In the new build system, what is the status of automatic symbol > >> generation, needed for easy debug. > >> > >> It is badly broken in 4.1.7, with most modules not getting symbols > >> generated despite --enable-symbols in the configure parameters. This has > >> cost me weeks of work on a debug project. > >> > >> On 7/4/2020 11:44 AM, Damjan Jovanovic wrote: > >>> Hi > >>> > >>> In the scons-build branch, I've just pushed a set of 11 commits that > >>> theoretically get 93 out of 105 gbuild modules (88.57%) automatically > >>> converting to gbuild. > >>> > >>> The "gotoSCons" converter and the SCons infrastructure in that branch > >> have > >>> now been developed to such a level that a module can be automatically > >>> converted from gbuild to SCons, from where it can use SCons for all of > >> the > >>> following: > >>> Building C/C++ objects > >>> Linking shared libraries, static libraries, and executables > >>> Building JUnit tests and running them > >>> Building Google Tests and running them > >>> Building .component files with XSLT > >>> Running Ant sub-builds > >>> Delivering "package" files such as headers > >>> Even doing the impossibly difficult 5 step "AllLangResTarget" (.src -> > >>> merged .src -> .srs -> .res for each language). > >>> > >>> I still have to implement Jar, Zip, UnoApi, WinResTarget and SdiTarget, > >> but > >>> I think only Jar and Zip are worth implementing automatic conversion > for, > >>> as SdiTarget and UnoApi are only used in 5 places each, and > WinResTarget > >> in > >>> only 2 places, which makes manual conversion for them easier. The > hardest > >>> conversions are already done. > >>> > >>> Where does this leave us? > >>> > >>> The gotoSCons converter can't support a number of features, like > >>> non-deterministic constructs (ifeq ($(GUI),UNX)), custom make rules, > >> etc. A > >>> module can only be automatically converted if it doesn't use the > >>> unsupported features. Currently, 35 modules use only supported > features, > >>> and can be converted automatically (this should increase to 39 modules > >> when > >>> I add Jar and Zip conversion). > >>> > >>> Another 58 modules use non-deterministic constructs or custom make > rules. > >>> Converting those 58 could be done through a semi-automated process, > which > >>> involves editing the gbuild files to remove the unsupported features, > >>> running the automated conversion on what is left, then manually > patching > >>> what was removed into the conversion results. Sometimes this is quick > and > >>> easy, at other times probably not. > >>> > >>> The final 12 modules use unsupported targets requiring a longer and > >> mostly > >>> manual conversion to SCons, though even there the supported targets > could > >>> be converted automatically. > >>> > >>> The SCons infrastructure does require some cleanup, as I was learning > >> while > >>> developing, and we still need library naming conversions, tests on > >>> Linux/WIndows/Mac, etc. > >>> > >>> The more I've used SCons, the more I've liked it. I've even started > using > >>> it in my own projects at work now. I've found a way to solve every > >> problem > >>> I've encountered, and the SCons developers have been helpful when I > asked > >>> them questions. Complex functionality like header dependency scanning, > >>> automatic directory creation for output files, using @responsefile for > >> long > >>> command lines when necessary, and other features gbuild implements > >>> manually, all work in SCons automatically. In 1816 lines of code, our > >> SCons > >>> infrastructure implements what took gbuild 9418 lines, and SCons is far > >>> more readable and maintainable (even in its current messy state). > >>> > >>> The plan isn't to merge this to trunk any time soon. Rather the idea is > >> to > >>> develop the converter even further, then when it's complete enough, > >> convert > >>> as many gbuild modules to SCons. Then measure performance of building > >> those > >>> modules en-masse with SCons alone - if there are performance problems > at > >>> that stage, they are only
Fixes for bootstrap?
Hi all I have managed to compile successfully branch 4.2.X under Ubuntu 18.04 x64 but there are some errors during download of external dependencies that maybe someone can fix? First situaton: download from http://hci.iwr.uni-heidelberg.de/vigra-old-versions/vigra1.6.0.tar.gz failed (404 Not Found) download failed This folder no longer exists. Is this link declared somewhere in the build system and could be corrected? Second situation: Many libraries are downloaded from sourceforge (which frequently has mirror issues). Couldn't these libraries be hosted on the AOO server? E.g. download from https://sourceforge.net/projects/dejavu/files/dejavu/2.37/dejavu-fonts-ttf-2.37.tar.bz2 failed (302 Found) download failed download from https://sourceforge.net/projects/boost/files/boost/1.55.0/boost_1_55_0.tar.bz2 failed (302 Found) etc Third situation: Downloaded modules checksums are not verified downloading dmake-4.12.tar.bz2 downloading to /source/openoffice/ext_sources/dmake-4.12.tar.bz2.part checksum not given, md5 of file is 266d817492d8259a640fad075461080e downloading epm-3.7.tar.gz downloading to /source/openoffice/ext_sources/epm-3.7.tar.gz.part checksum not given, md5 of file is 3ade8cfe7e59ca8e65052644fed9fca4 Can this be added? All other modules are verified Fourth situation: downloading to /source/openoffice/ext_sources/52654eb3b2e60c35731ea8fc87f1bd29-jpeg-8d.tar.gz.part MD5 checksum is OK The current version is jpegsrc.v9d.tar.gz Would it make sense to update to this version for branch 42X? version 8d is from Jan 2012 and 9d from Jan 2020 Thanks! Pedro
Re: Automated gbuild -> SCons convertibility now at 88.57%
On 7/4/2020 12:24 PM, Damjan Jovanovic wrote: Given how I've only developed on FreeBSD so far, anything Windows is probably at negative infinity :) > Do you have some example modules with that symbols problem, or at least know whether they are gbuild or dmake modules? c:\OpenOfficeDev\openoffice\main\scripting\source\protocolhandler\scripthandler.cxx does not have symbols. c:\OpenOfficeDev\openoffice\main\package\source\xstor\xstorage.cxx does have symbols generated. On Sat, Jul 4, 2020 at 9:13 PM Patricia Shanahan wrote: In the new build system, what is the status of automatic symbol generation, needed for easy debug. It is badly broken in 4.1.7, with most modules not getting symbols generated despite --enable-symbols in the configure parameters. This has cost me weeks of work on a debug project. On 7/4/2020 11:44 AM, Damjan Jovanovic wrote: Hi In the scons-build branch, I've just pushed a set of 11 commits that theoretically get 93 out of 105 gbuild modules (88.57%) automatically converting to gbuild. The "gotoSCons" converter and the SCons infrastructure in that branch have now been developed to such a level that a module can be automatically converted from gbuild to SCons, from where it can use SCons for all of the following: Building C/C++ objects Linking shared libraries, static libraries, and executables Building JUnit tests and running them Building Google Tests and running them Building .component files with XSLT Running Ant sub-builds Delivering "package" files such as headers Even doing the impossibly difficult 5 step "AllLangResTarget" (.src -> merged .src -> .srs -> .res for each language). I still have to implement Jar, Zip, UnoApi, WinResTarget and SdiTarget, but I think only Jar and Zip are worth implementing automatic conversion for, as SdiTarget and UnoApi are only used in 5 places each, and WinResTarget in only 2 places, which makes manual conversion for them easier. The hardest conversions are already done. Where does this leave us? The gotoSCons converter can't support a number of features, like non-deterministic constructs (ifeq ($(GUI),UNX)), custom make rules, etc. A module can only be automatically converted if it doesn't use the unsupported features. Currently, 35 modules use only supported features, and can be converted automatically (this should increase to 39 modules when I add Jar and Zip conversion). Another 58 modules use non-deterministic constructs or custom make rules. Converting those 58 could be done through a semi-automated process, which involves editing the gbuild files to remove the unsupported features, running the automated conversion on what is left, then manually patching what was removed into the conversion results. Sometimes this is quick and easy, at other times probably not. The final 12 modules use unsupported targets requiring a longer and mostly manual conversion to SCons, though even there the supported targets could be converted automatically. The SCons infrastructure does require some cleanup, as I was learning while developing, and we still need library naming conversions, tests on Linux/WIndows/Mac, etc. The more I've used SCons, the more I've liked it. I've even started using it in my own projects at work now. I've found a way to solve every problem I've encountered, and the SCons developers have been helpful when I asked them questions. Complex functionality like header dependency scanning, automatic directory creation for output files, using @responsefile for long command lines when necessary, and other features gbuild implements manually, all work in SCons automatically. In 1816 lines of code, our SCons infrastructure implements what took gbuild 9418 lines, and SCons is far more readable and maintainable (even in its current messy state). The plan isn't to merge this to trunk any time soon. Rather the idea is to develop the converter even further, then when it's complete enough, convert as many gbuild modules to SCons. Then measure performance of building those modules en-masse with SCons alone - if there are performance problems at that stage, they are only going to get worse with more modules. The real test however is converting the other 78 dmake modules to SCons. 37 of them are 3rd party "externals" like jpeg and zlib, which have their own build systems that we just call, so conversion is relatively easy. The other 41 modules are hard to convert, but gbuild is one of the reasons that they were hard, and where SCons is expected to make the greatest difference. Only once we are building without dmake, without gbuild, without build.pl, without Cygwin, on all platforms, then it would be the right time to merge to trunk. If at some stage in this process we are unhappy with SCons, and some better build system can be found, it shouldn't be difficult to change to it. The converter could output files for that other build system instead; at present it's only 498 lines of code in 1 file,
Re: Automated gbuild -> SCons convertibility now at 88.57%
Given how I've only developed on FreeBSD so far, anything Windows is probably at negative infinity :). Do you have some example modules with that symbols problem, or at least know whether they are gbuild or dmake modules? On Sat, Jul 4, 2020 at 9:13 PM Patricia Shanahan wrote: > In the new build system, what is the status of automatic symbol > generation, needed for easy debug. > > It is badly broken in 4.1.7, with most modules not getting symbols > generated despite --enable-symbols in the configure parameters. This has > cost me weeks of work on a debug project. > > On 7/4/2020 11:44 AM, Damjan Jovanovic wrote: > > Hi > > > > In the scons-build branch, I've just pushed a set of 11 commits that > > theoretically get 93 out of 105 gbuild modules (88.57%) automatically > > converting to gbuild. > > > > The "gotoSCons" converter and the SCons infrastructure in that branch > have > > now been developed to such a level that a module can be automatically > > converted from gbuild to SCons, from where it can use SCons for all of > the > > following: > > Building C/C++ objects > > Linking shared libraries, static libraries, and executables > > Building JUnit tests and running them > > Building Google Tests and running them > > Building .component files with XSLT > > Running Ant sub-builds > > Delivering "package" files such as headers > > Even doing the impossibly difficult 5 step "AllLangResTarget" (.src -> > > merged .src -> .srs -> .res for each language). > > > > I still have to implement Jar, Zip, UnoApi, WinResTarget and SdiTarget, > but > > I think only Jar and Zip are worth implementing automatic conversion for, > > as SdiTarget and UnoApi are only used in 5 places each, and WinResTarget > in > > only 2 places, which makes manual conversion for them easier. The hardest > > conversions are already done. > > > > Where does this leave us? > > > > The gotoSCons converter can't support a number of features, like > > non-deterministic constructs (ifeq ($(GUI),UNX)), custom make rules, > etc. A > > module can only be automatically converted if it doesn't use the > > unsupported features. Currently, 35 modules use only supported features, > > and can be converted automatically (this should increase to 39 modules > when > > I add Jar and Zip conversion). > > > > Another 58 modules use non-deterministic constructs or custom make rules. > > Converting those 58 could be done through a semi-automated process, which > > involves editing the gbuild files to remove the unsupported features, > > running the automated conversion on what is left, then manually patching > > what was removed into the conversion results. Sometimes this is quick and > > easy, at other times probably not. > > > > The final 12 modules use unsupported targets requiring a longer and > mostly > > manual conversion to SCons, though even there the supported targets could > > be converted automatically. > > > > The SCons infrastructure does require some cleanup, as I was learning > while > > developing, and we still need library naming conversions, tests on > > Linux/WIndows/Mac, etc. > > > > The more I've used SCons, the more I've liked it. I've even started using > > it in my own projects at work now. I've found a way to solve every > problem > > I've encountered, and the SCons developers have been helpful when I asked > > them questions. Complex functionality like header dependency scanning, > > automatic directory creation for output files, using @responsefile for > long > > command lines when necessary, and other features gbuild implements > > manually, all work in SCons automatically. In 1816 lines of code, our > SCons > > infrastructure implements what took gbuild 9418 lines, and SCons is far > > more readable and maintainable (even in its current messy state). > > > > The plan isn't to merge this to trunk any time soon. Rather the idea is > to > > develop the converter even further, then when it's complete enough, > convert > > as many gbuild modules to SCons. Then measure performance of building > those > > modules en-masse with SCons alone - if there are performance problems at > > that stage, they are only going to get worse with more modules. > > > > The real test however is converting the other 78 dmake modules to SCons. > 37 > > of them are 3rd party "externals" like jpeg and zlib, which have their > own > > build systems that we just call, so conversion is relatively easy. The > > other 41 modules are hard to convert, but gbuild is one of the reasons > that > > they were hard, and where SCons is expected to make the greatest > > difference. Only once we are building without dmake, without gbuild, > > without build.pl, without Cygwin, on all platforms, then it would be the > > right time to merge to trunk. > > > > If at some stage in this process we are unhappy with SCons, and some > better > > build system can be found, it shouldn't be difficult to change to it. The > > converter could output files for that other build system
Re: Automated gbuild -> SCons convertibility now at 88.57%
In the new build system, what is the status of automatic symbol generation, needed for easy debug. It is badly broken in 4.1.7, with most modules not getting symbols generated despite --enable-symbols in the configure parameters. This has cost me weeks of work on a debug project. On 7/4/2020 11:44 AM, Damjan Jovanovic wrote: Hi In the scons-build branch, I've just pushed a set of 11 commits that theoretically get 93 out of 105 gbuild modules (88.57%) automatically converting to gbuild. The "gotoSCons" converter and the SCons infrastructure in that branch have now been developed to such a level that a module can be automatically converted from gbuild to SCons, from where it can use SCons for all of the following: Building C/C++ objects Linking shared libraries, static libraries, and executables Building JUnit tests and running them Building Google Tests and running them Building .component files with XSLT Running Ant sub-builds Delivering "package" files such as headers Even doing the impossibly difficult 5 step "AllLangResTarget" (.src -> merged .src -> .srs -> .res for each language). I still have to implement Jar, Zip, UnoApi, WinResTarget and SdiTarget, but I think only Jar and Zip are worth implementing automatic conversion for, as SdiTarget and UnoApi are only used in 5 places each, and WinResTarget in only 2 places, which makes manual conversion for them easier. The hardest conversions are already done. Where does this leave us? The gotoSCons converter can't support a number of features, like non-deterministic constructs (ifeq ($(GUI),UNX)), custom make rules, etc. A module can only be automatically converted if it doesn't use the unsupported features. Currently, 35 modules use only supported features, and can be converted automatically (this should increase to 39 modules when I add Jar and Zip conversion). Another 58 modules use non-deterministic constructs or custom make rules. Converting those 58 could be done through a semi-automated process, which involves editing the gbuild files to remove the unsupported features, running the automated conversion on what is left, then manually patching what was removed into the conversion results. Sometimes this is quick and easy, at other times probably not. The final 12 modules use unsupported targets requiring a longer and mostly manual conversion to SCons, though even there the supported targets could be converted automatically. The SCons infrastructure does require some cleanup, as I was learning while developing, and we still need library naming conversions, tests on Linux/WIndows/Mac, etc. The more I've used SCons, the more I've liked it. I've even started using it in my own projects at work now. I've found a way to solve every problem I've encountered, and the SCons developers have been helpful when I asked them questions. Complex functionality like header dependency scanning, automatic directory creation for output files, using @responsefile for long command lines when necessary, and other features gbuild implements manually, all work in SCons automatically. In 1816 lines of code, our SCons infrastructure implements what took gbuild 9418 lines, and SCons is far more readable and maintainable (even in its current messy state). The plan isn't to merge this to trunk any time soon. Rather the idea is to develop the converter even further, then when it's complete enough, convert as many gbuild modules to SCons. Then measure performance of building those modules en-masse with SCons alone - if there are performance problems at that stage, they are only going to get worse with more modules. The real test however is converting the other 78 dmake modules to SCons. 37 of them are 3rd party "externals" like jpeg and zlib, which have their own build systems that we just call, so conversion is relatively easy. The other 41 modules are hard to convert, but gbuild is one of the reasons that they were hard, and where SCons is expected to make the greatest difference. Only once we are building without dmake, without gbuild, without build.pl, without Cygwin, on all platforms, then it would be the right time to merge to trunk. If at some stage in this process we are unhappy with SCons, and some better build system can be found, it shouldn't be difficult to change to it. The converter could output files for that other build system instead; at present it's only 498 lines of code in 1 file, that are involved in writing SCons build files, all we would need is a similar file for that other build system. Build systems are not the most exciting part of development, but bad build systems make development painful, and as a large multi-platform project, we build a lot. We answer build-related questions on the mailing lists too often, and new contributors are put off by the current build system. A lot of what we want to do with AOO, such as ports to Win64, AArch64, newer MSVC versions, and so on, also involve build-related changes. Damjan -- This email has
Automated gbuild -> SCons convertibility now at 88.57%
Hi In the scons-build branch, I've just pushed a set of 11 commits that theoretically get 93 out of 105 gbuild modules (88.57%) automatically converting to gbuild. The "gotoSCons" converter and the SCons infrastructure in that branch have now been developed to such a level that a module can be automatically converted from gbuild to SCons, from where it can use SCons for all of the following: Building C/C++ objects Linking shared libraries, static libraries, and executables Building JUnit tests and running them Building Google Tests and running them Building .component files with XSLT Running Ant sub-builds Delivering "package" files such as headers Even doing the impossibly difficult 5 step "AllLangResTarget" (.src -> merged .src -> .srs -> .res for each language). I still have to implement Jar, Zip, UnoApi, WinResTarget and SdiTarget, but I think only Jar and Zip are worth implementing automatic conversion for, as SdiTarget and UnoApi are only used in 5 places each, and WinResTarget in only 2 places, which makes manual conversion for them easier. The hardest conversions are already done. Where does this leave us? The gotoSCons converter can't support a number of features, like non-deterministic constructs (ifeq ($(GUI),UNX)), custom make rules, etc. A module can only be automatically converted if it doesn't use the unsupported features. Currently, 35 modules use only supported features, and can be converted automatically (this should increase to 39 modules when I add Jar and Zip conversion). Another 58 modules use non-deterministic constructs or custom make rules. Converting those 58 could be done through a semi-automated process, which involves editing the gbuild files to remove the unsupported features, running the automated conversion on what is left, then manually patching what was removed into the conversion results. Sometimes this is quick and easy, at other times probably not. The final 12 modules use unsupported targets requiring a longer and mostly manual conversion to SCons, though even there the supported targets could be converted automatically. The SCons infrastructure does require some cleanup, as I was learning while developing, and we still need library naming conversions, tests on Linux/WIndows/Mac, etc. The more I've used SCons, the more I've liked it. I've even started using it in my own projects at work now. I've found a way to solve every problem I've encountered, and the SCons developers have been helpful when I asked them questions. Complex functionality like header dependency scanning, automatic directory creation for output files, using @responsefile for long command lines when necessary, and other features gbuild implements manually, all work in SCons automatically. In 1816 lines of code, our SCons infrastructure implements what took gbuild 9418 lines, and SCons is far more readable and maintainable (even in its current messy state). The plan isn't to merge this to trunk any time soon. Rather the idea is to develop the converter even further, then when it's complete enough, convert as many gbuild modules to SCons. Then measure performance of building those modules en-masse with SCons alone - if there are performance problems at that stage, they are only going to get worse with more modules. The real test however is converting the other 78 dmake modules to SCons. 37 of them are 3rd party "externals" like jpeg and zlib, which have their own build systems that we just call, so conversion is relatively easy. The other 41 modules are hard to convert, but gbuild is one of the reasons that they were hard, and where SCons is expected to make the greatest difference. Only once we are building without dmake, without gbuild, without build.pl, without Cygwin, on all platforms, then it would be the right time to merge to trunk. If at some stage in this process we are unhappy with SCons, and some better build system can be found, it shouldn't be difficult to change to it. The converter could output files for that other build system instead; at present it's only 498 lines of code in 1 file, that are involved in writing SCons build files, all we would need is a similar file for that other build system. Build systems are not the most exciting part of development, but bad build systems make development painful, and as a large multi-platform project, we build a lot. We answer build-related questions on the mailing lists too often, and new contributors are put off by the current build system. A lot of what we want to do with AOO, such as ports to Win64, AArch64, newer MSVC versions, and so on, also involve build-related changes. Damjan
Re: should we conduct a 20 year anniversary online conference / meetup?
Hi Matthias, On 7/4/20 11:32 AM, Matthias Seidel wrote: Hi all, Bumping up this one again... Additionally, we have a virtual ApacheCon this year: https://apachecon.com/acna2020/ What about some talks about our project? Regards, Matthias I would definitely attend an online meetup unless the time of day was in the middle of my night or something. I was planning to attend ApacheCon now that is virtual. Doing presentations is definitely not my strongest ability but I have a topic I've been thinking about putting a presentation together for. I'm finishing up the documentation before I announce it on dev@ but I've finished an new extension to add Apache Groovy to AOO as a macro language and another extension that recreates most of the built-in macro examples in Groovy. The third project is the Groovy UNO project that I've updated after a long while. These are more AOO ecosystem and developer tool topics than directly project related so I'm not sure. Best regards, Carl Am 06.06.20 um 10:49 schrieb Matthias Seidel: Hi, Am 05.06.20 um 22:41 schrieb Peter Kovacs: Hello all, This year is Anniversary year. OpenOffice becomes 20, and we will be 9 Years TLP. So Mechtilde, Matthias and I thought maybe we should do some online conference. We thought maybe on Saturday the 17.10.2020. I would like to have the release of AOO 4.1.8 around that time. What about a customized "About" graphic like this? [1] Given our "speed" let's start early! Maybe we can put the Release Schedule for 4.1.8 online as a draft? [2] Regards, Matthias [1] https://home.apache.org/~mseidel/about_20yrs.png [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Releases Is there interest? What about the date? What could we do on the date? - Some discussion, meetup? plannings for the years to come? Who would attend? All the best Peter - 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: should we conduct a 20 year anniversary online conference / meetup?
Hi all, Bumping up this one again... Additionally, we have a virtual ApacheCon this year: https://apachecon.com/acna2020/ What about some talks about our project? Regards, Matthias Am 06.06.20 um 10:49 schrieb Matthias Seidel: > Hi, > > Am 05.06.20 um 22:41 schrieb Peter Kovacs: >> Hello all, >> >> >> This year is Anniversary year. >> >> OpenOffice becomes 20, and we will be 9 Years TLP. >> >> So Mechtilde, Matthias and I thought maybe we should do some online >> conference. >> >> We thought maybe on Saturday the 17.10.2020. > I would like to have the release of AOO 4.1.8 around that time. What > about a customized "About" graphic like this? [1] > > Given our "speed" let's start early! Maybe we can put the Release > Schedule for 4.1.8 online as a draft? [2] > > Regards, > > Matthias > > [1] https://home.apache.org/~mseidel/about_20yrs.png > [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Releases > >> >> Is there interest? What about the date? >> >> What could we do on the date? - Some discussion, meetup? plannings for >> the years to come? >> >> Who would attend? >> >> >> All the best >> >> Peter >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> smime.p7s Description: S/MIME Cryptographic Signature
[GitHub] [openoffice] Pilot-Pirx commented on pull request #89: Use std::vector instead of fixed-size array of cffLocal objects
Pilot-Pirx commented on pull request #89: URL: https://github.com/apache/openoffice/pull/89#issuecomment-653749584 As a first test I could build AOO42X on Windows with this patch applied. I could also successfully export a document to PDF with Noto Sans CJK font. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: New Committer: Detlef Nannen
Hello Jan-Christian, Am 03.07.20 um 17:57 schrieb jan-christ...@wienandt.de: > I can speak my mind on my own. That was also my guess. And that means we do not need a "tribunus plebis". Thank you for this clarification. Kind regards Michael signature.asc Description: OpenPGP digital signature
Re: A random message from Facebook
Am 03.07.20 um 07:07 schrieb Peter: Our rating on facebook is now 4.1. I wanted to pass on the comment of Esteban Juan José Guillén: "Thanks to Jesus, a complete free of charge and honest office application, Apache Open Office" thats great to see. Thanks for this great command. And, Peter, thanks for forwrding to the mailing list. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
