Re: [openoffice] branch trunk updated: Fix incorrect gbuild usage that can cause intermittent parallel build failures.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [openoffice] branch trunk updated: Fix incorrect gbuild usage that can cause intermittent parallel build failures.

Don Lewis-2
On  4 Oct, [hidden email] wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> truckman pushed a commit to branch trunk
> in repository https://gitbox.apache.org/repos/asf/openoffice.git
>
>
> The following commit(s) were added to refs/heads/trunk by this push:
>      new 7a50e16  Fix incorrect gbuild usage that can cause intermittent parallel build failures.
> 7a50e16 is described below
>
> commit 7a50e16f1d47cf9b54d012c17bef715ca3b060c8
> Author: Don Lewis <[hidden email]>
> AuthorDate: Fri Oct 4 09:29:16 2019 -0700
>
>     Fix incorrect gbuild usage that can cause intermittent parallel build failures.

I hadn't seen this problem until just recently, but I was observing
about a 50% failure rate in the codemaker module when doing
  build --all -P3 -- -P3
on my four CPU CentOS 6 VM.

>     There was some misuse of gbuild that was causing make rules to be added
>     that had solver/*/*/workdir/ExternalHeaders/Library and
>     solver/*/*/workdir/ExternalHeaders/Library listed as dependencies.
>     If these directories did not exist, then a pattern match rule intended
>     to create files under the
>     solver/*/*/workdir/ExternalHeaders/{Library,StaticLibrary} directories
>     would be triggered.  The recipe for that rule would then
>       mkdir -p solver/*/*/workdir/ExternalHeaders
>     and then
>       touch solver/*/*/workdir/ExternalHeaders/{Library,StaticLibrary}
>     creating it as a plain file.  A subsequent make rule would
>     unconditionally
>       mkdir -p solver/*/*/workdir/ExternalHeaders/{Library,StaticLibrary}
>     and fail.
>    
>     Fix the incorrect gbuild usage and add some sanity checks to gbuild
>     to catch the problem closer to the source and more deterministically.
> ---
>  main/codemaker/Executable_cppumaker.mk     | 4 ++--
>  main/codemaker/Executable_javamaker.mk     | 4 ++--
>  main/codemaker/StaticLibrary_codemaker.mk  | 2 +-
>  main/codemaker/StaticLibrary_commoncpp.mk  | 2 +-
>  main/codemaker/StaticLibrary_commonjava.mk | 2 +-
>  main/jvmfwk/Executable_javaldx.mk          | 2 +-
>  main/registry/Executable_checksingleton.mk | 2 +-
>  main/registry/Executable_rdbedit.mk        | 2 +-
>  main/registry/Executable_regcompare.mk     | 2 +-
>  main/registry/Executable_regmerge.mk       | 2 +-
>  main/registry/Executable_regview.mk        | 2 +-
>  main/solenv/gbuild/LinkTarget.mk           | 2 ++
>  12 files changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/main/codemaker/Executable_cppumaker.mk b/main/codemaker/Executable_cppumaker.mk
> index b876b68..63c9bc2 100644
> --- a/main/codemaker/Executable_cppumaker.mk
> +++ b/main/codemaker/Executable_cppumaker.mk
> @@ -25,9 +25,9 @@ $(eval $(call gb_Executable_Executable,cppumaker))
>  
>  $(eval $(call gb_Executable_set_targettype_gui,cppumaker,NO))
>  
> -$(eval $(call gb_StaticLibrary_add_package_headers,cppumaker,codemaker_inc))
> +$(eval $(call gb_Executable_add_package_headers,cppumaker,codemaker_inc))

Does anyone know why we call add_package_headers when building
executables?  When building libraries, we need to deliver the headers
for the library API, but I don't know why we would do this for an
executable.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [openoffice] branch trunk updated: Fix incorrect gbuild usage that can cause intermittent parallel build failures.

Damjan Jovanovic
On Fri, Oct 4, 2019 at 6:47 PM Don Lewis <[hidden email]> wrote:

> On  4 Oct, [hidden email] wrote:
>
> > diff --git a/main/codemaker/Executable_cppumaker.mk
> b/main/codemaker/Executable_cppumaker.mk
> > index b876b68..63c9bc2 100644
> > --- a/main/codemaker/Executable_cppumaker.mk
> > +++ b/main/codemaker/Executable_cppumaker.mk
> > @@ -25,9 +25,9 @@ $(eval $(call gb_Executable_Executable,cppumaker))
> >
> >  $(eval $(call gb_Executable_set_targettype_gui,cppumaker,NO))
> >
> > -$(eval $(call
> gb_StaticLibrary_add_package_headers,cppumaker,codemaker_inc))
> > +$(eval $(call
> gb_Executable_add_package_headers,cppumaker,codemaker_inc))
>
> Does anyone know why we call add_package_headers when building
> executables?  When building libraries, we need to deliver the headers
> for the library API, but I don't know why we would do this for an
> executable.
>
>
If you look at 529d6db8d002a57de885f2a2dfd65c2a89b9309e the old prj/d.lst
was delivering headers too, so I just did the same in gbuild.

Some other downstream module probably needs them.