FAQ
The revision log for the files various Win32 "canned config files"
win32/config_H.* suggest that they are updated manually and sporadically.

As best I can tell each is generated from a corresponding config file
using win32/config_h.PL, and I assume ideally is supposed to be in sync.

win32/config_h.PL is actually portable. Would it make sense to do the
regeneration as part of regen.pl, and (therefore) keep all the canned
headers up to date automatically?

Nicholas Clark

Search Discussions

  • Steve Hay at Aug 30, 2011 at 8:28 pm

    On 30 August 2011 09:32, Nicholas Clark wrote:
    The revision log for the files various Win32 "canned config files"
    win32/config_H.* suggest that they are updated manually and sporadically.
    Yes, I've updated them numerous times, but regettably haven't done so
    for a while. If you're looking at this area now, would it help or
    hinder you if I brought them up to date now?

    As best I can tell each is generated from a corresponding config file
    using win32/config_h.PL, and I assume ideally is supposed to be in sync.
    Essentially, yes. I do it using the regen_config_h target in
    win32/Makefile, plus some (too much...) hand-editing. There are some
    comments above that target which explain the process a little.

    win32/config_h.PL is actually portable. Would it make sense to do the
    regeneration as part of regen.pl, and (therefore) keep all the canned
    headers up to date automatically?
    It would be nice, and I've thought about it before, but never worked
    out a nice way to do it, given the amount of manual intervention
    involved every time I've done it.

    It involves building a perl with the various Makefile options all
    switched off (see d64224560b and 17bdc11416 for the reasoning) and
    then using that to run the regen_config_h target. (It would be
    simplest if miniperl.exe was used to run that target, since
    miniperl.exe is built with the various options switched off already,
    but I think it didn't work when I last tried it -- miniperl.exe can't
    load dynamic (DLL) extensions, and some were needed to run that target
    IIRC.) Then some hand-editing is required to put back the special
    __GNUC__ stuff which gets lost in that process (this is to allow
    building XS extensions with GCC in a perl (e.g. ActivePerl...) that
    was built with VC++), plus some stuff about QUAD_IS___INT64 got lost
    the last time I did it and also needed restoring (I think Merijn was
    going to update his magical Configure stuff to render that unnecessary
    in future).

    That's just for the VC++ 32-bit config. The VC++ 64-bit, GCC (32-bit)
    and BCC configs also need doing similarly (with _MSC_VER stuff needing
    to be restored in the GCC config after regeneration), plus a GCC
    64-bit config has arrived since I last did this.

    Some corners can be cut with the 64-bits being similar to the 32-bits
    (just copy the new 32-bit config and apply the same diffs as existed
    previously, provided that nothing new actually needs to differ between
    32-bit and 64-bit...), but it's still rather laborious and I would
    love to get it automated somehow.
  • Nicholas Clark at Aug 30, 2011 at 8:55 pm

    On Tue, Aug 30, 2011 at 09:28:33PM +0100, Steve Hay wrote:
    On 30 August 2011 09:32, Nicholas Clark wrote:
    The revision log for the files various Win32 "canned config files"
    win32/config_H.* suggest that they are updated manually and sporadically.
    Yes, I've updated them numerous times, but regettably haven't done so
    for a while. If you're looking at this area now, would it help or
    hinder you if I brought them up to date now?
    Definitely help.
    As best I can tell each is generated from a corresponding config file
    using win32/config_h.PL, and I assume ideally is supposed to be in sync.
    Essentially, yes. I do it using the regen_config_h target in
    win32/Makefile, plus some (too much...) hand-editing. There are some
    comments above that target which explain the process a little.
    Aha. I wasn't aware of that. Thanks.

    [Stuff to think about further]

    Nicholas Clark
  • Steve Hay at Sep 1, 2011 at 12:38 pm

    Nicholas Clark wrote on 2011-08-30:
    On Tue, Aug 30, 2011 at 09:28:33PM +0100, Steve Hay wrote:
    On 30 August 2011 09:32, Nicholas Clark wrote:
    The revision log for the files various Win32 "canned config files"
    win32/config_H.* suggest that they are updated manually and
    sporadically.
    Yes, I've updated them numerous times, but regettably haven't done so
    for a while. If you're looking at this area now, would it help or
    hinder you if I brought them up to date now?
    Definitely help.
    Ok, I've just finished doing that and committed the changes.
  • H.Merijn Brand at Aug 31, 2011 at 11:15 am

    On Tue, 30 Aug 2011 09:32:03 +0100, Nicholas Clark wrote:

    The revision log for the files various Win32 "canned config files"
    win32/config_H.* suggest that they are updated manually and sporadically.

    As best I can tell each is generated from a corresponding config file
    using win32/config_h.PL, and I assume ideally is supposed to be in sync.

    win32/config_h.PL is actually portable. Would it make sense to do the
    regeneration as part of regen.pl, and (therefore) keep all the canned
    headers up to date automatically?
    I manually change these based on Porting/checkcfgvar.pl

    will that be pointless too than?
    /me silently hopes so

    --
    H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
    using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
    11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
    http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
    http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
  • Steve Hay at Sep 1, 2011 at 12:52 pm

    H.Merijn Brand wrote on 2011-08-31:
    On Tue, 30 Aug 2011 09:32:03 +0100, Nicholas Clark wrote:

    The revision log for the files various Win32 "canned config files"
    win32/config_H.* suggest that they are updated manually and
    sporadically.

    As best I can tell each is generated from a corresponding config file
    using win32/config_h.PL, and I assume ideally is supposed to be in
    sync.
    win32/config_h.PL is actually portable. Would it make sense to do the
    regeneration as part of regen.pl, and (therefore) keep all the canned
    headers up to date automatically?
    I manually change these based on Porting/checkcfgvar.pl

    will that be pointless too than?
    /me silently hopes so
    It's the win32/config.* files that you (kindly) update with the help of
    Porting/checkcfgvar.pl. We're talking about the win32/config_H.* files
    here, which are not so easily updated...

    Btw, Merijn: One of the manual parts of the process of updating them is
    restoring QUADKIND 5 (QUAD_IS___INT64), which gets lost when running
    win32/config_h.PL because it isn't in config_h.SH. Is that something
    that you could sort out? (It was added to the win32 configs long ago in
    83ff24d4e9, but never found its way upstream.)
  • H.Merijn Brand at Sep 1, 2011 at 1:58 pm

    On Thu, 1 Sep 2011 13:52:33 +0100, "Steve Hay" wrote:

    H.Merijn Brand wrote on 2011-08-31:
    On Tue, 30 Aug 2011 09:32:03 +0100, Nicholas Clark wrote:

    The revision log for the files various Win32 "canned config files"
    win32/config_H.* suggest that they are updated manually and
    sporadically.

    As best I can tell each is generated from a corresponding config file
    using win32/config_h.PL, and I assume ideally is supposed to be in
    sync.
    win32/config_h.PL is actually portable. Would it make sense to do the
    regeneration as part of regen.pl, and (therefore) keep all the canned
    headers up to date automatically?
    I manually change these based on Porting/checkcfgvar.pl

    will that be pointless too than?
    /me silently hopes so
    It's the win32/config.* files that you (kindly) update with the help of
    Porting/checkcfgvar.pl. We're talking about the win32/config_H.* files
    here, which are not so easily updated...

    Btw, Merijn: One of the manual parts of the process of updating them is
    restoring QUADKIND 5 (QUAD_IS___INT64), which gets lost when running
    win32/config_h.PL because it isn't in config_h.SH. Is that something
    that you could sort out?
    Will be in my next update. Metaunit now updated.
    http://perl5.git.perl.org/metaconfig.git/commit/55db06f7a3707318f9094c
    (It was added to the win32 configs long ago in 83ff24d4e9, but never
    found its way upstream.)
    I'm not "triggered" by changes to win32 files :)

    I don't see how this change ought to make it into meta:

    --- a/win32/config_H.vc
    +++ b/win32/config_H.vc
    @@ -909,22 +909,25 @@
    /* HAS_QUAD:
    * This symbol, if defined, tells that there's a 64-bit integer type,
    * Quad_t, and its unsigned counterpar, Uquad_t. QUADKIND will be one
    - * of QUAD_IS_INT, QUAD_IS_LONG, QUAD_IS_LONG_LONG, or QUAD_IS_INT64_T.
    + * of QUAD_IS_INT, QUAD_IS_LONG, QUAD_IS_LONG_LONG, QUAD_IS_INT64_T.
    + * or QUAD_IS___INT64.
    */
    -/*#define HAS_QUAD /**/
    +#define HAS_QUAD /**/
    #ifdef HAS_QUAD
    # ifndef __GNUC__
    # define Quad_t __int64 /**/
    # define Uquad_t unsigned __int64 /**/
    +# define QUADKIND 5 /**/
    # else
    # define Quad_t long long /**/
    # define Uquad_t unsigned long long /**/
    +# define QUADKIND 3 /**/
    # endif
    -# define QUADKIND 5 /**/
    # define QUAD_IS_INT 1
    # define QUAD_IS_LONG 2
    # define QUAD_IS_LONG_LONG 3
    # define QUAD_IS_INT64_T 4
    +# define QUAD_IS___INT64 5
    #endif


    --
    H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
    using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
    11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
    http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
    http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
  • Steve Hay at Sep 1, 2011 at 2:14 pm

    H.Merijn Brand wrote on 2011-09-01:
    Btw, Merijn: One of the manual parts of the process of updating them
    is
    restoring QUADKIND 5 (QUAD_IS___INT64), which gets lost when running
    win32/config_h.PL because it isn't in config_h.SH. Is that something
    that you could sort out?
    Will be in my next update. Metaunit now updated.
    http://perl5.git.perl.org/metaconfig.git/commit/55db06f7a3707318f9094c
    Thanks.

    (It was added to the win32 configs long ago in 83ff24d4e9, but never
    found its way upstream.)
    I'm not "triggered" by changes to win32 files :)
    ;-)

    I don't see how this change ought to make it into meta:

    --- a/win32/config_H.vc
    +++ b/win32/config_H.vc
    @@ -909,22 +909,25 @@
    /* HAS_QUAD:
    * This symbol, if defined, tells that there's a 64-bit integer
    type, * Quad_t, and its unsigned counterpar, Uquad_t. QUADKIND
    will be
    one - * of QUAD_IS_INT, QUAD_IS_LONG, QUAD_IS_LONG_LONG, or
    QUAD_IS_INT64_T. + * of QUAD_IS_INT, QUAD_IS_LONG,
    QUAD_IS_LONG_LONG, QUAD_IS_INT64_T. + * or QUAD_IS___INT64.
    */
    -/*#define HAS_QUAD /**/
    +#define HAS_QUAD /**/
    #ifdef HAS_QUAD # ifndef __GNUC__ # define Quad_t __int64 /**/
    # define Uquad_t unsigned __int64 /**/ +# define QUADKIND 5
    /**/ # else # define Quad_t long long /**/ # define
    Uquad_t unsigned long long /**/ +# define QUADKIND 3
    /**/ # endif -# define QUADKIND 5 /**/ # define QUAD_IS_INT 1 #
    define QUAD_IS_LONG 2 # define QUAD_IS_LONG_LONG 3 #
    define QUAD_IS_INT64_T 4 +# define QUAD_IS___INT64 5 #endif
    [Hmm. Outlook's screwy quoting doesn't like that does it?!]

    It was just the QUAD_IS___INT64 definition (and comment) that I wanted
    for now, as you've done.

    There are numerous __GNUC__ tests throughout the VC++ files to support
    building XS extensions with GCC in a perl (e.g. ActivePerl) that was
    built with VC++, and likewise numerous _MSC_VER tests throughout the GCC
    files. I don't really have a plan for handling them at the moment, other
    than manually restoring them each time they've been regenerated by
    win32/config_h.PL...

    (Are there any precedents outside of Win32 for anything similar?)
  • Jan Dubois at Sep 1, 2011 at 6:13 pm

    On Thu, 01 Sep 2011, Steve Hay wrote:
    H.Merijn Brand wrote on 2011-09-01:
    There are numerous __GNUC__ tests throughout the VC++ files to support
    building XS extensions with GCC in a perl (e.g. ActivePerl) that was
    built with VC++, and likewise numerous _MSC_VER tests throughout the GCC
    files. I don't really have a plan for handling them at the moment, other
    than manually restoring them each time they've been regenerated by
    win32/config_h.PL...

    (Are there any precedents outside of Win32 for anything similar?)
    I don't think so. The Perl source distribution generally supports only
    building from source, on the target platform, and with the same compiler
    that will be used to build additional XS extensions.

    It is binary Perl distributions, like ActivePerl, or Apple's Perl, that
    support multiple configurations, selected at runtime, from a single
    installation of Perl. Most of the runtime adaption does happen at the
    Config.h level though, and not in the C level headers.

    I was planning to write a longer reply to this issue in the "is MULTIARCH
    useless" thread, which is actually strongly related to this issue. I
    just haven't found the time yet.

    Cheers,
    -Jan
  • Jan Dubois at Sep 1, 2011 at 6:18 pm

    On Thu, 01 Sep 2011, Jan Dubois wrote:
    It is binary Perl distributions, like ActivePerl, or Apple's Perl,
    that support multiple configurations, selected at runtime, from a
    single installation of Perl. Most of the runtime adaption does happen
    at the Config.h level though, and not in the C level headers.
    Oops, that should be Config.pm.

    Cheers,
    -Jan

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedAug 30, '11 at 4:46p
activeSep 1, '11 at 6:18p
posts10
users5
websiteperl.org

People

Translate

site design / logo © 2021 Grokbase