develooper Front page | perl.perl5.porters | Postings from October 2016

Re: [perl #129229] [PATCH] Fix Parallel Building

Thread Previous
From:
Aaron Crane
Date:
October 12, 2016 10:03
Subject:
Re: [perl #129229] [PATCH] Fix Parallel Building
Message ID:
CACmk_tuem8quAMQqC5pzw53n6Y1MQKCqxv9PXYTXvR4CbnE2WQ@mail.gmail.com
Tony Cook via RT <perlbug-followup@perl.org> wrote:
> In general this type of problem is easy to reproduce once you identify
> the target with missing dependencies - just build the target missing its deps:
>
>  $ ./Configure -des -Dusedevel && make -j6 MANIFEST.srt
>  ...
>  Can't locate Cwd.pm in @INC (you may need to install the Cwd module) (@INC contains: lib  ...
>  ...

Thanks, that's a very useful tip.

> Whether or not we should have a MANIFEST file, or if we have the file
> whether it should be sorted, the patch supplied depends on the dynamic
> Cwd$(DLSUFFIX) even when Cwd is being built statically, as with a -Uusedl or
> -Dstatic_ext=Cwd build.
>
> Something like the attached fixes that.
>
> diff --git a/Makefile.SH b/Makefile.SH
> index 511d6e3..487231d 100755
> --- a/Makefile.SH
> +++ b/Makefile.SH
> @@ -461,9 +461,20 @@ SH_to_target() {
>  SH='Makefile.SH cflags.SH config_h.SH makedepend.SH myconfig.SH runtests.SH pod/Makefile.SH'
>  shextract=`SH_to_target $SH`
>
> +case "$usedl$static_cwd" in
> +defineundef)
> +    manifest_deps="lib/auto/Cwd/Cwd\$(DLSUFFIX)"
> +    ;;
> +*)
> +    manifest_deps=
> +    ;;
> +esac

I started wondering why Porting/manisort needs Cwd at all. It turns
out that the sort_manifest() routine that does the heavy lifting is
defined in Porting/pod_lib.pl, which imports File::Find (for the
benefit of pods_to_install(), used by installman and pod/buildtoc);
and it's File::Find that actually needs Cwd.

So an alternative would be to restructure Porting/pod_lib.pl: either
by breaking sort_manifest() out into a separate library, or by
changing compile-time "use File::Find" into a run-time "require
File::Find" solely in pods_to_install(). I'm inclined to think either
of those would be a little better, from the point of view of reducing
the number of cross-dependencies (especially hidden ones) between
various parts of the build system. The latter option would be a
smaller patch, but I think putting it in its own library is actually
the clearest option.

See attached.

-- 
Aaron Crane ** http://aaroncrane.co.uk/

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About