develooper Front page | perl.perl5.porters | Postings from August 2012

RE: MSWin32-x86-multi-thread-64int for perl-5.18 ?

Thread Previous | Thread Next
From:
Steve Hay
Date:
August 1, 2012 10:23
Subject:
RE: MSWin32-x86-multi-thread-64int for perl-5.18 ?
Message ID:
1B32FF956ABF414C9BCE5E487A1497E70DF99DCB@ukmail02.planit.group
Steve Hay wrote on 2012-06-11:
> Sisyphus wrote on 2012-06-10:
>> All good so far - though I think I've used the same compiler as you.
>> I didn't actually get very far with the test suite. The failing TODO
>> tests in re/reg_eval_scope.t cause crashes, which results in the
>> termination of the running of the test suite.
> 
> I don't get the whole test suite terminating -- just a pop-up for the
> crashing test, which I dismiss and then the rest continues. The pop-up
> can also be disabled, of course.
> 
> 
>> 
>> A less important issue - in some discussion with kmx we noticed that,
>> although config.gc defines d_longdbl, it sets d_longlong to undef. And
>> in config_H.gc, HAS_LONG_DOUBLE is defined, but HAS_LONG_LONG is not.
>> 
>> These are probably inconsequential, but we felt they should be fixed -
>> if only for consistency, and to avoid confusion. (Unless, of course,
>> there are good reasons to not do this.) I've built my
>> MSWin32-x86-multi-thread-5.16.0 and
>> MSWin32-x86-multi-thread-64int-5.16.0 with both d_longlong and
>> HAS_LONG_LONG defined - just to see if it causes anything untoward to
>> happen. (No problems yet that I'm aware of.)
>> 
>> If it's agreed that these are appropriate changes, then now is
>> probably a good time to make them.
> 
> Thanks for the spot. I've fixed this in e4a93c7214.


Sorry it's taken so long, but I've finally got round to pushing changes for enabling a USE_64_BIT_INT makefile option for Windows (commit 1f64ae1564).

As expected, the approach I've taken is to dynamically edit existing config.h and config.sh templates rather than adding yet more canned configurations. I began by editing the existing *.gc64 / *.vc64 files since the 64-bit-int configurations don't differ much from them, and then realized that actually the *.gc64 / *.vc64 files don't differ much from the *.gc / *.vc files either, so I've actually deleted the four 64-bit canned configurations too!

We now only have one VC++ configuration (config.vc / config_H.vc) and one GCC configuration (config.gc / config_H.gc) and 64-bit-int or 64-bit variations are all based on them.

The config_H.* files can't be edited by miniperl.exe since they are used to build it, so the "editing" of them is done in the makefiles, by appending some lines which first #undef any lines involved in 64-bit-ness and then #define the appropriate values. Once we have miniperl.exe, the config.* files are edited by config_sh.PL to create config.sh, from which configpm creates Config_heavy.pl, and config_h.PL creates the real config.h (with which to build perl.exe) from config_h.SH (the config_H.* files are not used for that).

There is scope here for having just a single config_H.* / config.* pair since the VC++ and GCC pairs don't different much either, but I've not gone that far yet.

Thanks for the original patch which started this all off, Rob :-)

Thread Previous | Thread Next


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