You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Damjan Jovanovic <da...@apache.org> on 2016/07/20 07:53:07 UTC
Re: Any chance to merge the gbuild branch rather soonish?
I am back to gbuild, have moved my Windows VM's disk to the faster ext3
filesystem, and have begun doing the only thing I can think of to debug
this: manually "bisection testing" the gbuild-reintegration branch to try
isolate which patch causes the build performance regression.
There is 136 patches ported from the branches/gbuild branch that have been
merged in batches to branches/gbuild-reintegration.
Patch 129 builds in 341 minutes.
Patch 43 builds in 335 minutes.
So it must be one of the 42 most recent patches.
Currently compiling patch 16.
On Mon, May 23, 2016 at 11:26 PM, Kay Schenk <ka...@gmail.com> wrote:
> On 05/05/2016 10:51 AM, Damjan Jovanovic wrote:
>
>> Windows XP SP3 32-bit on a VirtualBox instance on FreeBSD, underlying
>> filesystem is ZFS which does cause I/O slowdown, but not enough to explain
>> this.
>>
>> Can't remember what compiler I installed; there are Windows SDK 7 and
>> Visual Studio 9 directories.
>>
>
> Despite the lag, I'd like to get back to this given all your effort so far.
>
> Do you still have your config.log? It should show in there what it found
> for the C compiler.
>
> OK, and maybe a crazy idea. Despite the fact that we're having problems
> with the Win7 build for our usual processing, would it be worth doing a
> merge INTO the guild branch and setting up an additional win buildbot for
> that?
>
>
>> SDK_PATH="/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0"
>> ./configure --with-frame-home="$SDK_PATH" --with-psdk-home="$SDK_PATH"
>> --with-midl-path="$SDK_PATH/bin"
>> --with-ant-home="/cygdrive/c/apache-ant-1.9.6" --with-dmake-url="
>> http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2"
>> --with-epm-url="
>> http://www.msweet.org/files/project2/epm-3.7-source.tar.gz"
>> --enable-pch --disable-atl --disable-activex --without-junit
>> --with-cl-home="/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC"
>> --with-csc-path="/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5"
>> --with-jdk-home="/cygdrive/c/Program Files/Java/jdk1.7.0"
>> --disable-directx
>> --with-package-format="installed" --enable-wiki-publisher
>>
>> I am currently thinking we will gain more from porting to Java, than
>> trying
>> to maintain a build system for the buggy, leaky, complex, crash-prone,
>> insecure languages that are C/C++.
>>
>
> I don't know if its C++, which is still very widely used for programming
> development, or our complicated code, of which I'm guessing, at least 25%
> could be eliminated.
>
>
>
>
>> On Thu, May 5, 2016 at 7:18 PM, Kay Schenk <ka...@gmail.com> wrote:
>>
>> On Tue, May 3, 2016 at 12:07 PM, Damjan Jovanovic <da...@apache.org>
>>> wrote:
>>>
>>> Unfortunately I discovered a major problem with the
>>>> gbuild-reintegration branch: on Windows, the build time of trunk is
>>>> about 3-4 hours, but it's over 12 hours to build gbuild-reintegration
>>>> :-(. I don't have time to investigate soon, nor do I know where to
>>>> even begin...
>>>>
>>>>
>>> Hi Damjan, and thanks for this update even it is disappointing.
>>>
>>> Could you share what the specifics are for the Windows platform you're
>>> using for the build?
>>>
>>> * specific Windows OS
>>> * C compiler and flags
>>> * build options
>>> *
>>>
>>> anything else?
>>>
>>> Thanks again for all your work on this. We can work this out.
>>>
>>>
>>>
>>>> On Tue, May 3, 2016 at 5:20 AM, Pedro Giffuni <pf...@apache.org> wrote:
>>>>
>>>>> Hello;
>>>>>
>>>>> FWIW, I am preparing a second round of spelling fixes ... it's a
>>>>> quite big change. I would prefer to do such changes *after* the
>>>>> new build system is in place though.
>>>>>
>>>>> I can deal easily with any breakage caused by the spelling fixes but
>>>>> it may not be very fun to have to fix again the build issues so I
>>>>> would really prefer to chose the battle field ahead of time ;).
>>>>>
>>>>> Pedro.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>
>>>>
>>>
>>> --
>>> ----------------------------------------------------------------------
>>> MzK
>>>
>>> "Time spent with cats is never wasted."
>>> -- Sigmund Freud
>>>
>>>
>>
> --
> --------------------------------------------
> MzK
>
> "Time spent with cats is never wasted."
> -- Sigmund Freud
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Any chance to merge the gbuild branch rather soonish?
Posted by "Kay Schenk@apache.org" <ks...@apache.org>.
On 07/30/2016 09:51 PM, Damjan Jovanovic wrote:
> The problem is definitely in r1409590, in the LinkTarget.mk patch.
>
> On Fri, Jul 29, 2016 at 2:12 AM, Damjan Jovanovic <da...@apache.org> wrote:
>
>> I've narrowed this Windows build performance regression down to the
>> original branches/gbuild commits 1409589 and 1409590, which go together and
>> can't be split up.
>>
>> * r1409589: gnumake4: #i117845#: LinkTarget.mk: fix dep-files for
>> GenCxxObjects:
>> pass the dep-file target explicitly as a parameter to the
>> Object__commands.
>> * r1409590: gnumake4: #i117845#: LinkTarget.mk: refactor dep-files:
>> introduce dependency from object dep-file to object.
>>
>> The make rules involved are complex and affect all platforms. Proceeding
>> further is a real PITA :-(.
>>
So sorry. :( Thanks again for all your hard effort!
>>
>>
>> On Fri, Jul 22, 2016 at 7:05 PM, Damjan Jovanovic <da...@apache.org>
>> wrote:
>>
>>> The Windows build performance regression first occurs in r1735004, which
>>> takes 676 minutes to build compared to 330 minutes in the commit just
>>> before it. Only wall clock time increases, "user" and "system" times remain
>>> the same.
>>>
>>> 4 patches from branches/gbuild were merged in that commit. 3 of them are
>>> rather complex and none jump out at me, so I'll have to do more splitting
>>> up and building to find the one responsible.
>>>
>>>
>>>
>>>
>>> On Wed, Jul 20, 2016 at 9:53 AM, Damjan Jovanovic <da...@apache.org>
>>> wrote:
>>>
>>>> I am back to gbuild, have moved my Windows VM's disk to the faster ext3
>>>> filesystem, and have begun doing the only thing I can think of to debug
>>>> this: manually "bisection testing" the gbuild-reintegration branch to try
>>>> isolate which patch causes the build performance regression.
>>>>
>>>> There is 136 patches ported from the branches/gbuild branch that have
>>>> been merged in batches to branches/gbuild-reintegration.
>>>> Patch 129 builds in 341 minutes.
>>>> Patch 43 builds in 335 minutes.
>>>>
>>>> So it must be one of the 42 most recent patches.
>>>> Currently compiling patch 16.
>>>>
>>>>
>>>> On Mon, May 23, 2016 at 11:26 PM, Kay Schenk <ka...@gmail.com>
>>>> wrote:
>>>>
>>>>> On 05/05/2016 10:51 AM, Damjan Jovanovic wrote:
>>>>>
>>>>>> Windows XP SP3 32-bit on a VirtualBox instance on FreeBSD, underlying
>>>>>> filesystem is ZFS which does cause I/O slowdown, but not enough to
>>>>>> explain
>>>>>> this.
>>>>>>
>>>>>> Can't remember what compiler I installed; there are Windows SDK 7 and
>>>>>> Visual Studio 9 directories.
>>>>>>
>>>>>
>>>>> Despite the lag, I'd like to get back to this given all your effort so
>>>>> far.
>>>>>
>>>>> Do you still have your config.log? It should show in there what it
>>>>> found for the C compiler.
>>>>>
>>>>> OK, and maybe a crazy idea. Despite the fact that we're having problems
>>>>> with the Win7 build for our usual processing, would it be worth doing a
>>>>> merge INTO the guild branch and setting up an additional win buildbot for
>>>>> that?
>>>>>
>>>>>
>>>>>> SDK_PATH="/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0"
>>>>>> ./configure --with-frame-home="$SDK_PATH" --with-psdk-home="$SDK_PATH"
>>>>>> --with-midl-path="$SDK_PATH/bin"
>>>>>> --with-ant-home="/cygdrive/c/apache-ant-1.9.6" --with-dmake-url="
>>>>>> http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2"
>>>>>> --with-epm-url="
>>>>>> http://www.msweet.org/files/project2/epm-3.7-source.tar.gz"
>>>>>> --enable-pch --disable-atl --disable-activex --without-junit
>>>>>> --with-cl-home="/cygdrive/c/Program Files/Microsoft Visual Studio
>>>>>> 9.0/VC"
>>>>>> --with-csc-path="/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5"
>>>>>> --with-jdk-home="/cygdrive/c/Program Files/Java/jdk1.7.0"
>>>>>> --disable-directx
>>>>>> --with-package-format="installed" --enable-wiki-publisher
>>>>>>
>>>>>> I am currently thinking we will gain more from porting to Java, than
>>>>>> trying
>>>>>> to maintain a build system for the buggy, leaky, complex, crash-prone,
>>>>>> insecure languages that are C/C++.
>>>>>>
>>>>>
>>>>> I don't know if its C++, which is still very widely used for
>>>>> programming development, or our complicated code, of which I'm guessing, at
>>>>> least 25% could be eliminated.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Thu, May 5, 2016 at 7:18 PM, Kay Schenk <ka...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> On Tue, May 3, 2016 at 12:07 PM, Damjan Jovanovic <da...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Unfortunately I discovered a major problem with the
>>>>>>>> gbuild-reintegration branch: on Windows, the build time of trunk is
>>>>>>>> about 3-4 hours, but it's over 12 hours to build gbuild-reintegration
>>>>>>>> :-(. I don't have time to investigate soon, nor do I know where to
>>>>>>>> even begin...
>>>>>>>>
>>>>>>>>
>>>>>>> \u200bHi Damjan, and thanks for this update even it is disappointing.
>>>>>>>
>>>>>>> Could you share what the specifics are for the Windows platform you're
>>>>>>> using for the build?
>>>>>>>
>>>>>>> * specific Windows OS
>>>>>>> * C compiler and flags
>>>>>>> * build options
>>>>>>> * \u200b
>>>>>>>
>>>>>>> \u200banything else?
>>>>>>>
>>>>>>> Thanks again for all your work on this. We can work this out.
>>>>>>> \u200b
>>>>>>>
>>>>>>>
>>>>>>>> On Tue, May 3, 2016 at 5:20 AM, Pedro Giffuni <pf...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hello;
>>>>>>>>>
>>>>>>>>> FWIW, I am preparing a second round of spelling fixes ... it's a
>>>>>>>>> quite big change. I would prefer to do such changes *after* the
>>>>>>>>> new build system is in place though.
>>>>>>>>>
>>>>>>>>> I can deal easily with any breakage caused by the spelling fixes but
>>>>>>>>> it may not be very fun to have to fix again the build issues so I
>>>>>>>>> would really prefer to chose the battle field ahead of time ;).
>>>>>>>>>
>>>>>>>>> Pedro.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ----------------------------------------------------------------------
>>>>>>> MzK
>>>>>>>
>>>>>>> "Time spent with cats is never wasted."
>>>>>>> -- Sigmund Freud
>>>>>>>
>>>>>>>
>>>>>>
>>>>> --
>>>>> --------------------------------------------
>>>>> MzK
>>>>>
>>>>> "Time spent with cats is never wasted."
>>>>> -- Sigmund Freud
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>
--
Kay Schenk
Apache OpenOffice
----------------------------------------
"Things work out best for those who make
the best of the way things work out."
-- John Wooden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Any chance to merge the gbuild branch rather soonish?
Posted by Damjan Jovanovic <da...@apache.org>.
The problem is definitely in r1409590, in the LinkTarget.mk patch.
On Fri, Jul 29, 2016 at 2:12 AM, Damjan Jovanovic <da...@apache.org> wrote:
> I've narrowed this Windows build performance regression down to the
> original branches/gbuild commits 1409589 and 1409590, which go together and
> can't be split up.
>
> * r1409589: gnumake4: #i117845#: LinkTarget.mk: fix dep-files for
> GenCxxObjects:
> pass the dep-file target explicitly as a parameter to the
> Object__commands.
> * r1409590: gnumake4: #i117845#: LinkTarget.mk: refactor dep-files:
> introduce dependency from object dep-file to object.
>
> The make rules involved are complex and affect all platforms. Proceeding
> further is a real PITA :-(.
>
>
>
> On Fri, Jul 22, 2016 at 7:05 PM, Damjan Jovanovic <da...@apache.org>
> wrote:
>
>> The Windows build performance regression first occurs in r1735004, which
>> takes 676 minutes to build compared to 330 minutes in the commit just
>> before it. Only wall clock time increases, "user" and "system" times remain
>> the same.
>>
>> 4 patches from branches/gbuild were merged in that commit. 3 of them are
>> rather complex and none jump out at me, so I'll have to do more splitting
>> up and building to find the one responsible.
>>
>>
>>
>>
>> On Wed, Jul 20, 2016 at 9:53 AM, Damjan Jovanovic <da...@apache.org>
>> wrote:
>>
>>> I am back to gbuild, have moved my Windows VM's disk to the faster ext3
>>> filesystem, and have begun doing the only thing I can think of to debug
>>> this: manually "bisection testing" the gbuild-reintegration branch to try
>>> isolate which patch causes the build performance regression.
>>>
>>> There is 136 patches ported from the branches/gbuild branch that have
>>> been merged in batches to branches/gbuild-reintegration.
>>> Patch 129 builds in 341 minutes.
>>> Patch 43 builds in 335 minutes.
>>>
>>> So it must be one of the 42 most recent patches.
>>> Currently compiling patch 16.
>>>
>>>
>>> On Mon, May 23, 2016 at 11:26 PM, Kay Schenk <ka...@gmail.com>
>>> wrote:
>>>
>>>> On 05/05/2016 10:51 AM, Damjan Jovanovic wrote:
>>>>
>>>>> Windows XP SP3 32-bit on a VirtualBox instance on FreeBSD, underlying
>>>>> filesystem is ZFS which does cause I/O slowdown, but not enough to
>>>>> explain
>>>>> this.
>>>>>
>>>>> Can't remember what compiler I installed; there are Windows SDK 7 and
>>>>> Visual Studio 9 directories.
>>>>>
>>>>
>>>> Despite the lag, I'd like to get back to this given all your effort so
>>>> far.
>>>>
>>>> Do you still have your config.log? It should show in there what it
>>>> found for the C compiler.
>>>>
>>>> OK, and maybe a crazy idea. Despite the fact that we're having problems
>>>> with the Win7 build for our usual processing, would it be worth doing a
>>>> merge INTO the guild branch and setting up an additional win buildbot for
>>>> that?
>>>>
>>>>
>>>>> SDK_PATH="/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0"
>>>>> ./configure --with-frame-home="$SDK_PATH" --with-psdk-home="$SDK_PATH"
>>>>> --with-midl-path="$SDK_PATH/bin"
>>>>> --with-ant-home="/cygdrive/c/apache-ant-1.9.6" --with-dmake-url="
>>>>> http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2"
>>>>> --with-epm-url="
>>>>> http://www.msweet.org/files/project2/epm-3.7-source.tar.gz"
>>>>> --enable-pch --disable-atl --disable-activex --without-junit
>>>>> --with-cl-home="/cygdrive/c/Program Files/Microsoft Visual Studio
>>>>> 9.0/VC"
>>>>> --with-csc-path="/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5"
>>>>> --with-jdk-home="/cygdrive/c/Program Files/Java/jdk1.7.0"
>>>>> --disable-directx
>>>>> --with-package-format="installed" --enable-wiki-publisher
>>>>>
>>>>> I am currently thinking we will gain more from porting to Java, than
>>>>> trying
>>>>> to maintain a build system for the buggy, leaky, complex, crash-prone,
>>>>> insecure languages that are C/C++.
>>>>>
>>>>
>>>> I don't know if its C++, which is still very widely used for
>>>> programming development, or our complicated code, of which I'm guessing, at
>>>> least 25% could be eliminated.
>>>>
>>>>
>>>>
>>>>
>>>>> On Thu, May 5, 2016 at 7:18 PM, Kay Schenk <ka...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> On Tue, May 3, 2016 at 12:07 PM, Damjan Jovanovic <da...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>> Unfortunately I discovered a major problem with the
>>>>>>> gbuild-reintegration branch: on Windows, the build time of trunk is
>>>>>>> about 3-4 hours, but it's over 12 hours to build gbuild-reintegration
>>>>>>> :-(. I don't have time to investigate soon, nor do I know where to
>>>>>>> even begin...
>>>>>>>
>>>>>>>
>>>>>> Hi Damjan, and thanks for this update even it is disappointing.
>>>>>>
>>>>>> Could you share what the specifics are for the Windows platform you're
>>>>>> using for the build?
>>>>>>
>>>>>> * specific Windows OS
>>>>>> * C compiler and flags
>>>>>> * build options
>>>>>> *
>>>>>>
>>>>>> anything else?
>>>>>>
>>>>>> Thanks again for all your work on this. We can work this out.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Tue, May 3, 2016 at 5:20 AM, Pedro Giffuni <pf...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello;
>>>>>>>>
>>>>>>>> FWIW, I am preparing a second round of spelling fixes ... it's a
>>>>>>>> quite big change. I would prefer to do such changes *after* the
>>>>>>>> new build system is in place though.
>>>>>>>>
>>>>>>>> I can deal easily with any breakage caused by the spelling fixes but
>>>>>>>> it may not be very fun to have to fix again the build issues so I
>>>>>>>> would really prefer to chose the battle field ahead of time ;).
>>>>>>>>
>>>>>>>> Pedro.
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> ----------------------------------------------------------------------
>>>>>> MzK
>>>>>>
>>>>>> "Time spent with cats is never wasted."
>>>>>> -- Sigmund Freud
>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> --------------------------------------------
>>>> MzK
>>>>
>>>> "Time spent with cats is never wasted."
>>>> -- Sigmund Freud
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>>>
>>>
>>
>
Re: Any chance to merge the gbuild branch rather soonish?
Posted by Damjan Jovanovic <da...@apache.org>.
I've narrowed this Windows build performance regression down to the
original branches/gbuild commits 1409589 and 1409590, which go together and
can't be split up.
* r1409589: gnumake4: #i117845#: LinkTarget.mk: fix dep-files for
GenCxxObjects:
pass the dep-file target explicitly as a parameter to the Object__commands.
* r1409590: gnumake4: #i117845#: LinkTarget.mk: refactor dep-files:
introduce dependency from object dep-file to object.
The make rules involved are complex and affect all platforms. Proceeding
further is a real PITA :-(.
On Fri, Jul 22, 2016 at 7:05 PM, Damjan Jovanovic <da...@apache.org> wrote:
> The Windows build performance regression first occurs in r1735004, which
> takes 676 minutes to build compared to 330 minutes in the commit just
> before it. Only wall clock time increases, "user" and "system" times remain
> the same.
>
> 4 patches from branches/gbuild were merged in that commit. 3 of them are
> rather complex and none jump out at me, so I'll have to do more splitting
> up and building to find the one responsible.
>
>
>
>
> On Wed, Jul 20, 2016 at 9:53 AM, Damjan Jovanovic <da...@apache.org>
> wrote:
>
>> I am back to gbuild, have moved my Windows VM's disk to the faster ext3
>> filesystem, and have begun doing the only thing I can think of to debug
>> this: manually "bisection testing" the gbuild-reintegration branch to try
>> isolate which patch causes the build performance regression.
>>
>> There is 136 patches ported from the branches/gbuild branch that have
>> been merged in batches to branches/gbuild-reintegration.
>> Patch 129 builds in 341 minutes.
>> Patch 43 builds in 335 minutes.
>>
>> So it must be one of the 42 most recent patches.
>> Currently compiling patch 16.
>>
>>
>> On Mon, May 23, 2016 at 11:26 PM, Kay Schenk <ka...@gmail.com>
>> wrote:
>>
>>> On 05/05/2016 10:51 AM, Damjan Jovanovic wrote:
>>>
>>>> Windows XP SP3 32-bit on a VirtualBox instance on FreeBSD, underlying
>>>> filesystem is ZFS which does cause I/O slowdown, but not enough to
>>>> explain
>>>> this.
>>>>
>>>> Can't remember what compiler I installed; there are Windows SDK 7 and
>>>> Visual Studio 9 directories.
>>>>
>>>
>>> Despite the lag, I'd like to get back to this given all your effort so
>>> far.
>>>
>>> Do you still have your config.log? It should show in there what it found
>>> for the C compiler.
>>>
>>> OK, and maybe a crazy idea. Despite the fact that we're having problems
>>> with the Win7 build for our usual processing, would it be worth doing a
>>> merge INTO the guild branch and setting up an additional win buildbot for
>>> that?
>>>
>>>
>>>> SDK_PATH="/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0"
>>>> ./configure --with-frame-home="$SDK_PATH" --with-psdk-home="$SDK_PATH"
>>>> --with-midl-path="$SDK_PATH/bin"
>>>> --with-ant-home="/cygdrive/c/apache-ant-1.9.6" --with-dmake-url="
>>>> http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2"
>>>> --with-epm-url="
>>>> http://www.msweet.org/files/project2/epm-3.7-source.tar.gz"
>>>> --enable-pch --disable-atl --disable-activex --without-junit
>>>> --with-cl-home="/cygdrive/c/Program Files/Microsoft Visual Studio
>>>> 9.0/VC"
>>>> --with-csc-path="/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5"
>>>> --with-jdk-home="/cygdrive/c/Program Files/Java/jdk1.7.0"
>>>> --disable-directx
>>>> --with-package-format="installed" --enable-wiki-publisher
>>>>
>>>> I am currently thinking we will gain more from porting to Java, than
>>>> trying
>>>> to maintain a build system for the buggy, leaky, complex, crash-prone,
>>>> insecure languages that are C/C++.
>>>>
>>>
>>> I don't know if its C++, which is still very widely used for programming
>>> development, or our complicated code, of which I'm guessing, at least 25%
>>> could be eliminated.
>>>
>>>
>>>
>>>
>>>> On Thu, May 5, 2016 at 7:18 PM, Kay Schenk <ka...@gmail.com>
>>>> wrote:
>>>>
>>>> On Tue, May 3, 2016 at 12:07 PM, Damjan Jovanovic <da...@apache.org>
>>>>> wrote:
>>>>>
>>>>> Unfortunately I discovered a major problem with the
>>>>>> gbuild-reintegration branch: on Windows, the build time of trunk is
>>>>>> about 3-4 hours, but it's over 12 hours to build gbuild-reintegration
>>>>>> :-(. I don't have time to investigate soon, nor do I know where to
>>>>>> even begin...
>>>>>>
>>>>>>
>>>>> Hi Damjan, and thanks for this update even it is disappointing.
>>>>>
>>>>> Could you share what the specifics are for the Windows platform you're
>>>>> using for the build?
>>>>>
>>>>> * specific Windows OS
>>>>> * C compiler and flags
>>>>> * build options
>>>>> *
>>>>>
>>>>> anything else?
>>>>>
>>>>> Thanks again for all your work on this. We can work this out.
>>>>>
>>>>>
>>>>>
>>>>>> On Tue, May 3, 2016 at 5:20 AM, Pedro Giffuni <pf...@apache.org> wrote:
>>>>>>
>>>>>>> Hello;
>>>>>>>
>>>>>>> FWIW, I am preparing a second round of spelling fixes ... it's a
>>>>>>> quite big change. I would prefer to do such changes *after* the
>>>>>>> new build system is in place though.
>>>>>>>
>>>>>>> I can deal easily with any breakage caused by the spelling fixes but
>>>>>>> it may not be very fun to have to fix again the build issues so I
>>>>>>> would really prefer to chose the battle field ahead of time ;).
>>>>>>>
>>>>>>> Pedro.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> ----------------------------------------------------------------------
>>>>> MzK
>>>>>
>>>>> "Time spent with cats is never wasted."
>>>>> -- Sigmund Freud
>>>>>
>>>>>
>>>>
>>> --
>>> --------------------------------------------
>>> MzK
>>>
>>> "Time spent with cats is never wasted."
>>> -- Sigmund Freud
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>>
>
Re: Any chance to merge the gbuild branch rather soonish?
Posted by Damjan Jovanovic <da...@apache.org>.
The Windows build performance regression first occurs in r1735004, which
takes 676 minutes to build compared to 330 minutes in the commit just
before it. Only wall clock time increases, "user" and "system" times remain
the same.
4 patches from branches/gbuild were merged in that commit. 3 of them are
rather complex and none jump out at me, so I'll have to do more splitting
up and building to find the one responsible.
On Wed, Jul 20, 2016 at 9:53 AM, Damjan Jovanovic <da...@apache.org> wrote:
> I am back to gbuild, have moved my Windows VM's disk to the faster ext3
> filesystem, and have begun doing the only thing I can think of to debug
> this: manually "bisection testing" the gbuild-reintegration branch to try
> isolate which patch causes the build performance regression.
>
> There is 136 patches ported from the branches/gbuild branch that have been
> merged in batches to branches/gbuild-reintegration.
> Patch 129 builds in 341 minutes.
> Patch 43 builds in 335 minutes.
>
> So it must be one of the 42 most recent patches.
> Currently compiling patch 16.
>
>
> On Mon, May 23, 2016 at 11:26 PM, Kay Schenk <ka...@gmail.com> wrote:
>
>> On 05/05/2016 10:51 AM, Damjan Jovanovic wrote:
>>
>>> Windows XP SP3 32-bit on a VirtualBox instance on FreeBSD, underlying
>>> filesystem is ZFS which does cause I/O slowdown, but not enough to
>>> explain
>>> this.
>>>
>>> Can't remember what compiler I installed; there are Windows SDK 7 and
>>> Visual Studio 9 directories.
>>>
>>
>> Despite the lag, I'd like to get back to this given all your effort so
>> far.
>>
>> Do you still have your config.log? It should show in there what it found
>> for the C compiler.
>>
>> OK, and maybe a crazy idea. Despite the fact that we're having problems
>> with the Win7 build for our usual processing, would it be worth doing a
>> merge INTO the guild branch and setting up an additional win buildbot for
>> that?
>>
>>
>>> SDK_PATH="/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0"
>>> ./configure --with-frame-home="$SDK_PATH" --with-psdk-home="$SDK_PATH"
>>> --with-midl-path="$SDK_PATH/bin"
>>> --with-ant-home="/cygdrive/c/apache-ant-1.9.6" --with-dmake-url="
>>> http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2"
>>> --with-epm-url="
>>> http://www.msweet.org/files/project2/epm-3.7-source.tar.gz"
>>> --enable-pch --disable-atl --disable-activex --without-junit
>>> --with-cl-home="/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC"
>>> --with-csc-path="/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5"
>>> --with-jdk-home="/cygdrive/c/Program Files/Java/jdk1.7.0"
>>> --disable-directx
>>> --with-package-format="installed" --enable-wiki-publisher
>>>
>>> I am currently thinking we will gain more from porting to Java, than
>>> trying
>>> to maintain a build system for the buggy, leaky, complex, crash-prone,
>>> insecure languages that are C/C++.
>>>
>>
>> I don't know if its C++, which is still very widely used for programming
>> development, or our complicated code, of which I'm guessing, at least 25%
>> could be eliminated.
>>
>>
>>
>>
>>> On Thu, May 5, 2016 at 7:18 PM, Kay Schenk <ka...@gmail.com> wrote:
>>>
>>> On Tue, May 3, 2016 at 12:07 PM, Damjan Jovanovic <da...@apache.org>
>>>> wrote:
>>>>
>>>> Unfortunately I discovered a major problem with the
>>>>> gbuild-reintegration branch: on Windows, the build time of trunk is
>>>>> about 3-4 hours, but it's over 12 hours to build gbuild-reintegration
>>>>> :-(. I don't have time to investigate soon, nor do I know where to
>>>>> even begin...
>>>>>
>>>>>
>>>> Hi Damjan, and thanks for this update even it is disappointing.
>>>>
>>>> Could you share what the specifics are for the Windows platform you're
>>>> using for the build?
>>>>
>>>> * specific Windows OS
>>>> * C compiler and flags
>>>> * build options
>>>> *
>>>>
>>>> anything else?
>>>>
>>>> Thanks again for all your work on this. We can work this out.
>>>>
>>>>
>>>>
>>>>> On Tue, May 3, 2016 at 5:20 AM, Pedro Giffuni <pf...@apache.org> wrote:
>>>>>
>>>>>> Hello;
>>>>>>
>>>>>> FWIW, I am preparing a second round of spelling fixes ... it's a
>>>>>> quite big change. I would prefer to do such changes *after* the
>>>>>> new build system is in place though.
>>>>>>
>>>>>> I can deal easily with any breakage caused by the spelling fixes but
>>>>>> it may not be very fun to have to fix again the build issues so I
>>>>>> would really prefer to chose the battle field ahead of time ;).
>>>>>>
>>>>>> Pedro.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> ----------------------------------------------------------------------
>>>> MzK
>>>>
>>>> "Time spent with cats is never wasted."
>>>> -- Sigmund Freud
>>>>
>>>>
>>>
>> --
>> --------------------------------------------
>> MzK
>>
>> "Time spent with cats is never wasted."
>> -- Sigmund Freud
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>