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

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

Thread Previous
From:
Sisyphus
Date:
August 1, 2012 18:05
Subject:
Re: MSWin32-x86-multi-thread-64int for perl-5.18 ?
Message ID:
81A83C78DA1B493B80C450CED6BC05F5@desktop2

----- Original Message ----- 
From: "Steve Hay" <Steve.Hay@verosoftware.com>
To: "Steve Hay" <Steve.Hay@verosoftware.com>; "Sisyphus" 
<sisyphus1@optusnet.com.au>; "Steve Hay" <steve.m.hay@googlemail.com>
Cc: "bulk 88" <bulk88@hotmail.com>; <perl5-porters@perl.org>; "kmx" 
<kmx@volny.cz>
Sent: Thursday, August 02, 2012 3:23 AM
Subject: RE: MSWin32-x86-multi-thread-64int for perl-5.18 ?


> 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 :-)
>

And thank *you*, Steve, for picking it up and re-structuring it into its 
current form.
Btw, the original patch was really kmx's work .... so I can't even take any 
credit for that ;-)

Cheers,
Rob 


Thread Previous


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