FAQ

On Sun Feb 09 18:18:03 2014, bulk88 wrote:

patches used for testing

-----------------------------------------------------------------------------------------
win32/win32.h | 1 +
1 file changed, 1 insertion(+)

diff --git a/win32/win32.h b/win32/win32.h
index 3d1655a..f5f0187 100644
--- a/win32/win32.h
+++ b/win32/win32.h
@@ -20,6 +20,7 @@
* level in full perl
*/
# define WIN32_NO_SOCKETS
+# define PERL_DISABLE_PMC
#endif

#ifdef WIN32_NO_SOCKETS

----------------------------------------------------------------------------------------
write_buildcustomize.pl | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/write_buildcustomize.pl b/write_buildcustomize.pl
index 64bf4ce..181a00b 100644
--- a/write_buildcustomize.pl
+++ b/write_buildcustomize.pl
@@ -54,7 +54,7 @@ require File::Spec::Functions;

my $inc = join ",\n ",
map { "q\0$_\0" }
- (map {File::Spec::Functions::rel2abs($_)} @toolchain, 'lib');
+ (map {File::Spec::Functions::rel2abs($_)} 'lib', @toolchain);

open my $fh, '>', $file
or die "Can't open $file: $!";
@@ -74,6 +74,8 @@ print $fh <<"EOT" or $error = "Can't print to $file:
$!";
# We are miniperl, building extensions
# Replace the first entry of \@INC ("lib") with the list of
# directories we need.
+
+\${^WIN32_SLOPPY_STAT} = 1;
splice(\@INC, 0, 1, $inc);
\$^O = '$osname';
EOT
To get this ticket moving. So I will make a patch with all 3 optimizations above, and all 3 optimizations are done only on Win32? With all the discussion above, AFAIK the consensus is none of the 3 optimizations can be done on anything but Win32. Any final objections to the proposal in this post that would prevent the future patch from being applied?

--
bulk88 ~ bulk88 at hotmail.com

---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=121119

Search Discussions

  • bulk88 via RT at Mar 1, 2014 at 11:22 am

    On Fri Feb 28 18:53:40 2014, bulk88 wrote:
    To get this ticket moving. So I will make a patch with all 3
    optimizations above, and all 3 optimizations are done only on Win32?
    With all the discussion above, AFAIK the consensus is none of the 3
    optimizations can be done on anything but Win32. Any final objections
    to the proposal in this post that would prevent the future patch from
    being applied?
    Since I had time. I made the patch. Passed a harness run for me (me=Win32 platform only).

    --
    bulk88 ~ bulk88 at hotmail.com

    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=121119
  • bulk88 via RT at Mar 19, 2014 at 12:17 am

    On Sat Mar 01 03:22:06 2014, bulk88 wrote:
    On Fri Feb 28 18:53:40 2014, bulk88 wrote:
    To get this ticket moving. So I will make a patch with all 3
    optimizations above, and all 3 optimizations are done only on Win32?
    With all the discussion above, AFAIK the consensus is none of the 3
    optimizations can be done on anything but Win32. Any final objections
    to the proposal in this post that would prevent the future patch from
    being applied?
    Since I had time. I made the patch. Passed a harness run for me
    (me=Win32 platform only).
    Bump.

    --
    bulk88 ~ bulk88 at hotmail.com

    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=121119
  • Zefram at Mar 25, 2014 at 9:07 am
    Comment copied from the p5p thread on 5.20 blockers:

    I'd be happier about it if we actually resolved the commented reason for
    lib being last. It shouldn't be hard to arrange for new files in lib
    to be created under temporary names and atomically renamed into place.
    This may be a bit much to do for 5.20, though, especially with it having
    not been implemented yet. I'd lean towards punting to 5.21.

    -zefram
  • Tony Cook at Mar 25, 2014 at 10:40 pm

    On Tue, Mar 25, 2014 at 09:06:58AM +0000, Zefram wrote:
    Comment copied from the p5p thread on 5.20 blockers:

    I'd be happier about it if we actually resolved the commented reason for
    lib being last. It shouldn't be hard to arrange for new files in lib
    to be created under temporary names and atomically renamed into place.
    This may be a bit much to do for 5.20, though, especially with it having
    not been implemented yet. I'd lean towards punting to 5.21.
    While I think rename into place is a good idea, if Win32 does ever get
    parallel builds, lib will still have to go last, so an update of a
    module (on a remake) doesn't fail because another process is reading
    it.

    Tony
  • bulk88 via RT at Mar 26, 2014 at 1:14 am

    On Tue Mar 25 02:07:22 2014, zefram@fysh.org wrote:
    Comment copied from the p5p thread on 5.20 blockers:

    I'd be happier about it if we actually resolved the commented reason for
    lib being last. It shouldn't be hard to arrange for new files in lib
    to be created under temporary names and atomically renamed into place.
    This may be a bit much to do for 5.20, though, especially with it having
    not been implemented yet. I'd lean towards punting to 5.21.

    -zefram
    related https://rt.perl.org/Ticket/Display.html?id=82194 ?

    --
    bulk88 ~ bulk88 at hotmail.com

    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=121119
  • Zefram at Mar 26, 2014 at 9:27 am

    Yes, related.

    -zefram

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedMar 1, '14 at 2:53a
activeMar 26, '14 at 9:27a
posts7
users3
websiteperl.org

People

Translate

site design / logo © 2021 Grokbase