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 config.sh/config.h 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 extensions.mk, 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 needed. At this point it's just brainstorming which has at least inspired a little discussion. TonyThread Previous