Who will attend ApacheCon Europe?
Hi all I wonder who will go to the ApacheCon Europe in Budapest? Are there same people from Apache OpenOffice there? Have an nice day Raphael - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Who will attend ApacheCon Europe?
Raphael Bircher wrote: I wonder who will go to the ApacheCon Europe in Budapest? Are there same people from Apache OpenOffice there? Sure. Speakers listed at http://apacheconeu2014.sched.org/overview/type/openoffice will surely be there, and hopefully many more. Note that there is a gathering for an OpenOffice community meeting after Rony's talk, at the end of the conference day on Tuesday. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Build System Improvements
As you may know, in the past years I have made a couple of experiments regarding the build system of AOO. With the resulting experience I would now like to start to work on improving the build system. I have in mind a soft conversion that gradually replaces parts of the existing build system, not a big push that takes years to complete and then breaks everything. I would like to start with some under-the-hood changes to how the build process is controlled. At the moment we have prj/build.lst files that control how build.pl builds the dmake modules. Then there are makefiles.mk in directories of dmake modules and finally we have makefiles in gbuild modules. All of them are not makefiles in the classical sense, i.e. they seldomly contain directives of how to build a target. They are data files that primarily define dependencies between targets or, for example, which object files go into a shared library. They use three different, mostly unspecified and undocumented, notations. The first work item would be the conversion of these files into a unified XML syntax. At first these XML files would be converted back to the old syntax on-demand and on-the-fly so that the old build tool chain can still be used. Subsequent steps would then improve or replace parts of this tool chain. If you don't object to this general plan then I would start the XML conversion with the prj/build.lst files as proof of concept. I would also start to write Wiki pages that explain in more detail how the current build process works, what its draw backs are, and how, in my opinion, it can be improved. Best regards, Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Who will attend ApacheCon Europe?
Hi Andrea Am 17.10.14 08:46, schrieb Andrea Pescetti: Raphael Bircher wrote: I wonder who will go to the ApacheCon Europe in Budapest? Are there same people from Apache OpenOffice there? Sure. Speakers listed at http://apacheconeu2014.sched.org/overview/type/openoffice will surely be there, and hopefully many more. Note that there is a gathering for an OpenOffice community meeting after Rony's talk, at the end of the conference day on Tuesday. This sounds good. But is at Tuesday evening not a general committer event? Regards Raphael - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Build System Improvements
On 17/10/14 09:32, Andre Fischer wrote: As you may know, in the past years I have made a couple of experiments regarding the build system of AOO. With the resulting experience I would now like to start to work on improving the build system. I have in mind a soft conversion that gradually replaces parts of the existing build system, not a big push that takes years to complete and then breaks everything. I would like to start with some under-the-hood changes to how the build process is controlled. At the moment we have prj/build.lst files that control how build.pl builds the dmake modules. Then there are makefiles.mk in directories of dmake modules and finally we have makefiles in gbuild modules. All of them are not makefiles in the classical sense, i.e. they seldomly contain directives of how to build a target. They are data files that primarily define dependencies between targets or, for example, which object files go into a shared library. They use three different, mostly unspecified and undocumented, notations. The first work item would be the conversion of these files into a unified XML syntax. At first these XML files would be converted back to the old syntax on-demand and on-the-fly so that the old build tool chain can still be used. Subsequent steps would then improve or replace parts of this tool chain. If you don't object to this general plan then I would start the XML conversion with the prj/build.lst files as proof of concept. I would also start to write Wiki pages that explain in more detail how the current build process works, what its draw backs are, and how, in my opinion, it can be improved. everything that help us with the build system is welcome and hopefully we can drop the crap of the gbuild stuff instead of completing it. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Build System Improvements
Hi Andre, will these in the long term lead to a system, where AOO can be build directly in MS Visual Studio without need of cygwin? Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Recommend to extend the AOO 4.1.1 release notes based on tests on Windows 2012
On 17/10/14 11:13, Yuzhen Fan wrote: Hi All, During AOO 4.1.1 full regression test, I did basic tests on Windows 2012 and get them passed. In order to get sufficient tests to extend the release notes for 4.1.1, Juergen Meyer has executed further expended tests. The result is positive as 82% passed and 18% failed. Please note, these 18% tests fail with AOO3.4.1 on Windows 2003 in the same way they fail with AOO 4.1.1 on Windows 2012. As for 4.1.1, it has the same level of support as for 3.4.1, I would initial the discussion and propose that we extend the 4.1.1 release notes by adding support for Windows 2012. that are good news and from my perspective your idea to extend the release notes for AOO 4.1.1 is a good one. Windows 2012 server is replacing Windows 2003 server more and more and it is good when we can mark this platform as supported. Your tests have shown that we reached the same level of support as for Windows 2003. I believe 2003 server was not well tested in the past and it was more a relict from former days. It is very good that you + Juergen have taken the time to run these tests to ensure that we work on this platform. I definitely support this idea and give my +1 Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Build System Improvements
On 17.10.2014 13:21, Regina Henschel wrote: Hi Andre, will these in the long term lead to a system, where AOO can be build directly in MS Visual Studio without need of cygwin? Hi Regina, this is not a direct goal but could become possible as a side effect. One of the key ideas of the proposed approach is to further separate between dependencies and build logic and have scripts/programs transform the dependencies into actual make files. Once the dependencies are present as uniform XML files we can more easily write a transformation into Visual Studio solution files. But this will still not be a trivial task. It would help me if you or somebody else could provide a description or even a specification of Visual Studio solution/project files. -Andre Kind regards Regina - 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: Build System Improvements
orcnote inline below. -Original Message- From: Andre Fischer [mailto:awf@gmail.com] Sent: Friday, October 17, 2014 04:39 To: dev@openoffice.apache.org Subject: Re: Build System Improvements On 17.10.2014 13:21, Regina Henschel wrote: Hi Andre, will these in the long term lead to a system, where AOO can be build directly in MS Visual Studio without need of cygwin? Hi Regina, this is not a direct goal but could become possible as a side effect. One of the key ideas of the proposed approach is to further separate between dependencies and build logic and have scripts/programs transform the dependencies into actual make files. Once the dependencies are present as uniform XML files we can more easily write a transformation into Visual Studio solution files. But this will still not be a trivial task. It would help me if you or somebody else could provide a description or even a specification of Visual Studio solution/project files. orcnote I don't think you need to go all the way to solution files in order To compile native (win32 and x64) for Windows using Visual Studio, even Visual Studio 2013 Express for the Desktop. One can have makefile- controlled builds and command-line compiles just fine. Developers might want to create makefile solution files, but they should not be needed in the source tree. (It might also be valuable to understand MSBuild, which is XML-based already, and that might be a better alternative to constructing solution files. Finally, one reason to make a solution file is to use VS 2013 GIT repository integration, but that only works if pull requests become supported and cloning is to places where pulls can reach.) I think an interesting aspect of Andre's proposal is that one could Take advantage of linking and DLL creation more, not requiring full builds so much so long as there are unchanged static libraries and DLLs. This kind of refactoring might also be important for configurations on limited platforms. The idea is to build and test AOO by component layers. That might make working with GIT more practical as well. (I don't mean releasing separate components, but being able to build up dependencies in stages, even the first time as a way to start working with a fresh clone/checkout of the source tree. Of course, building smaller, specialized distros might be more-easily come by.) /orcnote -Andre Kind regards Regina - 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: Build System Improvements
On Fri, Oct 17, 2014 at 12:32 AM, Andre Fischer awf@gmail.com wrote: As you may know, in the past years I have made a couple of experiments regarding the build system of AOO. With the resulting experience I would now like to start to work on improving the build system. I have in mind a soft conversion that gradually replaces parts of the existing build system, not a big push that takes years to complete and then breaks everything. I would like to start with some under-the-hood changes to how the build process is controlled. At the moment we have prj/build.lst files that control how build.pl builds the dmake modules. Then there are makefiles.mk in directories of dmake modules and finally we have makefiles in gbuild modules. All of them are not makefiles in the classical sense, i.e. they seldomly contain directives of how to build a target. They are data files that primarily define dependencies between targets or, for example, which object files go into a shared library. They use three different, mostly unspecified and undocumented, notations. The first work item would be the conversion of these files into a unified XML syntax. At first these XML files would be converted back to the old syntax on-demand and on-the-fly so that the old build tool chain can still be used. Q: Could a build change like this just be used for SOME modules without having to convert back? Subsequent steps would then improve or replace parts of this tool chain. If you don't object to this general plan then I would start the XML conversion with the prj/build.lst files as proof of concept. I would also start to write Wiki pages that explain in more detail how the current build process works, what its draw backs are, and how, in my opinion, it can be improved. Best regards, Andre This sounds interesting and I can't wait to see what happens next! Is this Ant-like? Or can be used by Ant...which we use already for some things? -- - MzK Success breeds complacency. Complacency breeds failure. Only the paranoid survive. -- Andy Grove, Intel Co-founder
