develooper Front page | perl.perl5.porters | Postings from April 2018

Re: [perl #133070] [PATCH] fix parallel ALL_STATIC Win32 build

Thread Previous
Tony Cook
April 17, 2018 00:29
Re: [perl #133070] [PATCH] fix parallel ALL_STATIC Win32 build
Message ID:
On Mon, Apr 16, 2018 at 10:54:02AM -0700, bulk88 via RT wrote:
> On Sun, 08 Apr 2018 21:03:16 -0700, tonyc wrote:
> > Thanks, applied as 908f2cb56527d29c9176e478fa7eee0d02a7c77e.
> > 
> > There's still a problem if you build with STATIC_EXT=Unicode/Normalize
> > but that might be more difficult to fix.
> > 
> > I do wonder if the Win32 build should build miniperl, then use that to
> > build the final and generate a Makefile for the
> > full perl from there.
> > 
> > Tony
> What will generate the makefile? Makefile.SH would have to be rewritten in PP.

Well, it wouldn't match Makefile.SH anyway, since it doesn't need to
build miniperl.

> IMO its pointless because Windows doesn't come with a "Unix shell" compiler and M4 compiler out of the box and switching to Visual C with Autoconf+Bash (I've built such FOSS projects before) is insane since not even Unix perl uses M4 or autoconf. I know you wrote one patch 2 yrs ago that generates an auxiliary extensions only makefile for parallel extension building so each extension can be parallelzed to infinity cores instead of the 4 "categories" of extensions building side by side they way they do now and doesn't saturate all cores.

It would at least fix building with STATIC_EXT=Unicode/Normalize.

It may be possible to improve parallel building over my,
since with that the main makefile can't depend on individual
extensions, or it will risk the sub-makefile and the main makefile
trying to build the same extension at the same time, while if they're
in the same file a target can depend on the .dll or $(PERL_EXE) as

At this point it's just brainstorming which has at least inspired a
little discussion.


Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About