openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Lewis <truck...@apache.org>
Subject Re: [openoffice] branch trunk updated: Fix incorrect gbuild usage that can cause intermittent parallel build failures.
Date Fri, 04 Oct 2019 16:47:38 GMT
On  4 Oct, truckman@apache.org 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 <truckman@apache.org>
> 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: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message