-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strawberry perl 5.40.1.1, 5.38.3.1, 5.34.3.1 #233
base: master
Are you sure you want to change the base?
Conversation
Otherwise we get errors like ``` ..\perl.exe -f ..\pod\buildtoc -q ..\pod\buildtoc: perl5401delta.pod is known by buildtoc but does not exist ..\pod\buildtoc: Can't open file 'pod/perl5401delta.pod' for perl5401delta: No such file or directory ABORTED ```
We get many test failures with -O2 -fno-inline-functions
Also use libxslt 1.1.39 built with that version of libxml2. Its version is unchanged.
This allows consistency with 5.40.0.
Temporary code as a proof of concept. Should either be its own step or an optional argument.
Was a copy-paste error
Adding comments causes downstream issues with a few CPAN mods.
This makes it more obvious that a module is upgraded. Something in the code is uninstalling the original, which might not be what we want.
@@ -29,7 +29,7 @@ sub run { | |||
# Now go through the loop for each module. | |||
my $i = 0; | |||
for my $module (@list) { | |||
my $item = { module=> $module->{cpan_file}, install_to=>'perl' }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was deliberate on my part "back in the day..."
Given that, why would we want to pack up and install two versions of the same module?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for noting this. FWIW, I had assumed it was deliberate.
The original motivation for the latest change is in #221 where the Socket build differs when built with core or from CPAN. Perl 5.40 came with the latest version of Socket so it was not updated in the CPAN update step of the SP build.
Having run a few dev builds with this set, the P::D::S code is uninstalling the core modules first so we don't actually package both versions. The directories are left behind, though. I also have not yet tracked down where the uninstall is happening.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original motivation for the latest change is in #221
I think you could alternatively apply the patch at Perl/perl5@0404e25 - though I'm not sure whether that would count as an improvement over your current option ;-)
I don't know why that PR has not been merged. I presume it's just part of the general arrogant and apathetic disregard for Windows, but maybe it actually poses some problem of which I'm unaware.
I've been using that patch without any issue in my monthly builds of devel perl (beginning with perl-5.41.4 or perl-5.41.5), and it seems to be working fine. (My testing of the functionality is, however, not rigorous.)
I think there are a number of other symbols in those Windows config files that could and should also be defined - but I don't feel confident of being able to correctly identify them.
Besides, if the changes identified by that patch are being ignored, then I don't see much point in identifying other candidates for alteration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are changing some of the related defines before the build. If there are good reasons then we can add more.
Perl-Dist-Strawberry/share/64bit-5.40.1.1.pp
Lines 94 to 113 in 56d14cc
'config_H.gc' => { | |
I_DBM => 'define', | |
I_GDBM => 'define', | |
I_NDBM => 'define', | |
HAS_BUILTIN_CHOOSE_EXPR => 'define', | |
HAS_SYMLINK => 'define', | |
HAS_ISFINITE => 'define', # part of https://github.com/Perl/perl5/pull/22257 | |
}, | |
'config.gc' => { # see Step.pm for list of default updates | |
d_builtin_choose_expr => 'define', | |
d_mkstemp => 'define', | |
d_ndbm => 'define', | |
d_symlink => 'define', # many cpan modules fail tests when defined | |
i_db => 'define', | |
i_dbm => 'define', | |
i_gdbm => 'define', | |
i_ndbm => 'define', | |
d_isfinite => 'define', # part of https://github.com/Perl/perl5/pull/22257 | |
osvers => '10', | |
}, |
Installing updated core modules to the vendor
dir has the advantage that it is then clear that they are not the versions distributed with that version of perl.
@csjewell raises the valid point that we might be distributing two versions of the same module. This could lead to confusion if users manually set the PERL5LIB
paths and switch the order of the perl\vendor\lib
and perl\lib
dirs, but the build system seems to be uninstalling from perl\lib
so this problem should not manifest on users systems. (This does need to be more thoroughly checked, though).
Coming back to Socket
, an alternative approach is to force a rebuild in one of the CPAN install steps.
Currently two settings, one for core, one for cpan.
Build core with the same set as SP 5.40.0.1, and CPAN with -O2. See discussion and links in #232
This makes it clearer when the core was built with different flags than the CPAN modules.
Skip tests that fail due to path lengths, rather than all tests.
This allows separate release notes for the PDL edition, for example.
This hopefully makes it clearer it is not a standard perl entry.
Just an update. I have a 5.34.3 build that can be released and will do so later this week. The 5.38.3 and 5.40.1 releases are waiting on resolution of Perl/perl5#23022, and related patching of the SP builds. |
Updates #231 and #124