[python] patch for python.jam for setting suffix on HP-UX
There is a logic in python.jam setting suffix for Boost.Python extension files on HP-UX depending on version of Python interpreter. This logic does not take into account the fact that on HP-UX PA-RISC, the suffix must be ".sl", regardless of the version of Python interpreter (I myself was not aware of this fact before yesterday when I saw the results of Boost.Python tests on HP-UX_pa_risc_gcc with Python 2.5: the tests compile, but fail at run time). Attached patch fixes the problem. Verified on HP-UX PA-RISC with Python 2.5. Verified on HP-UX ia64 with Python 2.3 and 2.5 that it does not cause any regression. The patch relies on bjam setting correctly OSPLAT variable, so, for bjam compiled with aC++ on HP-UX ia64, the patch for jam.h in http://lists.boost.org/boost-build/2007/11/17975.php should be committed first. Ok to commit? Thanks, Boris Index: tools/python.jam =================================================================== --- tools/python.jam (revision 41021) +++ tools/python.jam (working copy) @@ -991,7 +991,9 @@ case cygwin : suffix = dll ; case hpux : { - if [ feature.get-values python : $(condition) ] in 1.5 1.6 2.0 2.1 2.2 2.3 2.4 + platform = [ modules.peek : OSPLAT ] ; + if $(platform) != IA64 || + [ feature.get-values python : $(condition) ] in 1.5 1.6 2.0 2.1 2.2 2.3 2.4 { suffix = sl ; }
Boris Gubenko wrote:
Attached patch fixes the problem. Verified on HP-UX PA-RISC with Python 2.5. Verified on HP-UX ia64 with Python 2.3 and 2.5 that it does not cause any regression. The patch relies on bjam setting correctly OSPLAT variable, so, for bjam compiled with aC++ on HP-UX ia64, the patch for jam.h in
http://lists.boost.org/boost-build/2007/11/17975.php
should be committed first.
Ok to commit?
Ping? (the patch in http://lists.boost.org/boost-build/2007/11/17975.php was committed a couple of days ago). If I don't hear any objections in the next few days, I'll commit the patch for python.jam to trunk. It affects only HP-UX platforms and was tested on these platforms. Thanks, Boris ----- Original Message ----- From: "Boris Gubenko" <Boris.Gubenko@hp.com> To: <boost@lists.boost.org> Cc: "Boris Gubenko" <Boris.Gubenko@hp.com> Sent: Monday, November 12, 2007 6:09 PM Subject: [boost] [python] patch for python.jam for setting suffix on HP-UX
There is a logic in python.jam setting suffix for Boost.Python extension files on HP-UX depending on version of Python interpreter. This logic does not take into account the fact that on HP-UX PA-RISC, the suffix must be ".sl", regardless of the version of Python interpreter (I myself was not aware of this fact before yesterday when I saw the results of Boost.Python tests on HP-UX_pa_risc_gcc with Python 2.5: the tests compile, but fail at run time).
Attached patch fixes the problem. Verified on HP-UX PA-RISC with Python 2.5. Verified on HP-UX ia64 with Python 2.3 and 2.5 that it does not cause any regression. The patch relies on bjam setting correctly OSPLAT variable, so, for bjam compiled with aC++ on HP-UX ia64, the patch for jam.h in
http://lists.boost.org/boost-build/2007/11/17975.php
should be committed first.
Ok to commit?
Thanks, Boris
Index: tools/python.jam =================================================================== --- tools/python.jam (revision 41021) +++ tools/python.jam (working copy) @@ -991,7 +991,9 @@ case cygwin : suffix = dll ; case hpux : { - if [ feature.get-values python : $(condition) ] in 1.5 1.6 2.0 2.1 2.2 2.3 2.4 + platform = [ modules.peek : OSPLAT ] ; + if $(platform) != IA64 || + [ feature.get-values python : $(condition) ] in 1.5 1.6 2.0 2.1 2.2 2.3 2.4 { suffix = sl ; }
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Mon Nov 12 2007, "Boris Gubenko" <Boris.Gubenko-AT-hp.com> wrote:
There is a logic in python.jam setting suffix for Boost.Python extension files on HP-UX depending on version of Python interpreter. This logic does not take into account the fact that on HP-UX PA-RISC, the suffix must be ".sl", regardless of the version of Python interpreter (I myself was not aware of this fact before yesterday when I saw the results of Boost.Python tests on HP-UX_pa_risc_gcc with Python 2.5: the tests compile, but fail at run time).
Attached patch fixes the problem. Verified on HP-UX PA-RISC with Python 2.5. Verified on HP-UX ia64 with Python 2.3 and 2.5 that it does not cause any regression. The patch relies on bjam setting correctly OSPLAT variable, so, for bjam compiled with aC++ on HP-UX ia64, the patch for jam.h in
http://lists.boost.org/boost-build/2007/11/17975.php
should be committed first.
Ok to commit?
Thanks, Boris
Index: tools/python.jam =================================================================== --- tools/python.jam (revision 41021) +++ tools/python.jam (working copy) @@ -991,7 +991,9 @@ case cygwin : suffix = dll ; case hpux : { - if [ feature.get-values python : $(condition) ] in 1.5 1.6 2.0 2.1 2.2 2.3 2.4 + platform = [ modules.peek : OSPLAT ] ; + if $(platform) != IA64 || + [ feature.get-values python : $(condition) ] in 1.5 1.6 2.0 2.1 2.2 2.3 2.4 { suffix = sl ; }
Boris, I don't think this is really the recommended way to determine the platform, is it? Could you check with Volodya? Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
I don't think this is really the recommended way to determine the platform, is it? Could you check with Volodya?
I "stole" it from tools/build/v2/util/os.jam : .platform = [ modules.peek : OSPLAT ] ; I need to distinguish two different architectures of HP-UX: ia64 and PA-RISC. I'm copying Volodya on the reply, in case he does not watch this thread. Thanks, Boris ----- Original Message ----- From: "David Abrahams" <dave@boost-consulting.com> To: <boost@lists.boost.org> Sent: Friday, November 16, 2007 1:20 PM Subject: Re: [boost] [python] patch for python.jam for setting suffix onHP-UX
on Mon Nov 12 2007, "Boris Gubenko" <Boris.Gubenko-AT-hp.com> wrote:
There is a logic in python.jam setting suffix for Boost.Python extension files on HP-UX depending on version of Python interpreter. This logic does not take into account the fact that on HP-UX PA-RISC, the suffix must be ".sl", regardless of the version of Python interpreter (I myself was not aware of this fact before yesterday when I saw the results of Boost.Python tests on HP-UX_pa_risc_gcc with Python 2.5: the tests compile, but fail at run time).
Attached patch fixes the problem. Verified on HP-UX PA-RISC with Python 2.5. Verified on HP-UX ia64 with Python 2.3 and 2.5 that it does not cause any regression. The patch relies on bjam setting correctly OSPLAT variable, so, for bjam compiled with aC++ on HP-UX ia64, the patch for jam.h in
http://lists.boost.org/boost-build/2007/11/17975.php
should be committed first.
Ok to commit?
Thanks, Boris
Index: tools/python.jam =================================================================== --- tools/python.jam (revision 41021) +++ tools/python.jam (working copy) @@ -991,7 +991,9 @@ case cygwin : suffix = dll ; case hpux : { - if [ feature.get-values python : $(condition) ] in 1.5 1.6 2.0 2.1 2.2 2.3 2.4 + platform = [ modules.peek : OSPLAT ] ; + if $(platform) != IA64 || + [ feature.get-values python : $(condition) ] in 1.5 1.6 2.0 2.1 2.2 2.3 2.4 { suffix = sl ; }
Boris,
I don't think this is really the recommended way to determine the platform, is it? Could you check with Volodya?
Thanks,
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Fri Nov 16 2007, "Boris Gubenko" <Boris.Gubenko-AT-hp.com> wrote:
David Abrahams wrote:
I don't think this is really the recommended way to determine the platform, is it? Could you check with Volodya?
I "stole" it from tools/build/v2/util/os.jam :
.platform = [ modules.peek : OSPLAT ] ;
Yeah; isn't there a function in os.jam that lets you get that value?
I need to distinguish two different architectures of HP-UX: ia64 and PA-RISC.
I'm copying Volodya on the reply, in case he does not watch this thread.
OK -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Yeah; isn't there a function in os.jam that lets you get that value?
I'm not sure what function you mean. I can use 'os.platform' instead of 'modules.peek : OSPLAT' (I wish I used it in the first place). Is 'os.platform' the recommended way to determine the platform or there is a better way? Thanks, Boris ----- Original Message ----- From: "David Abrahams" <dave@boost-consulting.com> To: <boost@lists.boost.org> Cc: "Vladimir Prus" <ghost@cs.msu.su> Sent: Saturday, November 17, 2007 5:04 PM Subject: Re: [boost] [python] patch for python.jam for setting suffix onHP-UX
on Fri Nov 16 2007, "Boris Gubenko" <Boris.Gubenko-AT-hp.com> wrote:
David Abrahams wrote:
I don't think this is really the recommended way to determine the platform, is it? Could you check with Volodya?
I "stole" it from tools/build/v2/util/os.jam :
.platform = [ modules.peek : OSPLAT ] ;
Yeah; isn't there a function in os.jam that lets you get that value?
I need to distinguish two different architectures of HP-UX: ia64 and PA-RISC.
I'm copying Volodya on the reply, in case he does not watch this thread.
OK
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris Gubenko wrote:
David Abrahams wrote:
Yeah; isn't there a function in os.jam that lets you get that value?
I'm not sure what function you mean. I can use 'os.platform' instead of 'modules.peek : OSPLAT' (I wish I used it in the first place).
Is 'os.platform' the recommended way to determine the platform or there is a better way?
As your goal is to figure out the suffix (extension), you can ask python for that directly, since python clearly needs to know what filenames to look for when importing modules. LIBEXT=`$PYTHON -c "from distutils import sysconfig; print sysconfig.get_config_var('SO')" | tr -d "\r"` ...is what I do in my configure.ac script. FWIW, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Boris Gubenko wrote:
David Abrahams wrote:
Yeah; isn't there a function in os.jam that lets you get that value? I'm not sure what function you mean. I can use 'os.platform' instead of 'modules.peek : OSPLAT' (I wish I used it in the first place).
Is 'os.platform' the recommended way to determine the platform or there is a better way?
As your goal is to figure out the suffix (extension), you can ask python for that directly, since python clearly needs to know what filenames to look for when importing modules.
LIBEXT=`$PYTHON -c "from distutils import sysconfig; print sysconfig.get_config_var('SO')" | tr -d "\r"`
...is what I do in my configure.ac script.
It has drawback that it doesn't work if one wants to do cross-compiles. Which is why we avoid system runtime tests, one exception being asking the compiler what version it is. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Boris Gubenko wrote:
David Abrahams wrote:
I don't think this is really the recommended way to determine the platform, is it? Could you check with Volodya?
I "stole" it from tools/build/v2/util/os.jam :
.platform = [ modules.peek : OSPLAT ] ;
I need to distinguish two different architectures of HP-UX: ia64 and PA-RISC.
Looking at more of the context of python.jam what you want is to select based on the <architecture> feature. Something like: if ! [ feature.get-values architecture : $(condition) ] in ia64 || [ feature.get-values python : $(condition) ] in 1.5 1.6 2.0 2.1 2.2 2.3 2.4 { suffix = sl ; } else { suffix = so ; } I notice though that we don't have pa-risc in the set of architectures: # Type of CPU architecture to compile for. feature architecture : # x86 and x86-64 x86 # ia64 ia64 # Sparc sparc # RS/6000 & PowerPC power # MIPS/SGI mips1 mips2 mips3 mips4 mips32 mips32r2 mips64 # : propagated optional ; I can add in "hppa" or "parisc". Or do you prefer something else? Similar question for the instruction-set feature. I can add in "pa-risc-1-0", "pa-risc-1-1", and "pa-risc-2-0". Or do you prefer a different nomenclature? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Looking at more of the context of python.jam what you want is to select based on the <architecture> feature. Something like:
if ! [ feature.get-values architecture : $(condition) ] in ia64 || [ feature.get-values python : $(condition) ] in 1.5 1.6 2.0 2.1 2.2 2.3 2.4 { suffix = sl ; } else { suffix = so ; }
I can use '! [ feature.get-values architecture : $(condition) ] in ia64' or I can use '[ os.platform ] != IA64' (I tested the latter during the weekend). Which one is preferable?
I notice though that we don't have pa-risc in the set of architectures: [...] I can add in "hppa" or "parisc". Or do you prefer something else? Similar question for the instruction-set feature. I can add in "pa-risc-1-0", "pa-risc-1-1", and "pa-risc-2-0". Or do you prefer a different nomenclature?
Thank you for the proposal! I think, "parisc" as an architecture is fine. For now, we can test PA-RISC as not ia64, but what if HP-UX is ported to a different architecture? :-) As for the instruction-set, I'm not sure how it is used. Why would we need "pa-risc-1-0", pa-risc-1-1" and "pa-risc-2-0" instead of a single name? Also, while we are at it: can we define OSPLAT for PA-RISC in jam.h: # if defined( __hpux ) && defined( __hppa ) # define OSPLAT "OSPLAT=PARISC" # endif If there are no objections, I can make this change in the trunk. Thanks again, Boris ----- Original Message ----- From: "Rene Rivera" <grafikrobot@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, November 18, 2007 2:22 PM Subject: Re: [boost] [python] patch for python.jam for setting suffix onHP-UX
Boris Gubenko wrote:
David Abrahams wrote:
I don't think this is really the recommended way to determine the platform, is it? Could you check with Volodya?
I "stole" it from tools/build/v2/util/os.jam :
.platform = [ modules.peek : OSPLAT ] ;
I need to distinguish two different architectures of HP-UX: ia64 and PA-RISC.
Looking at more of the context of python.jam what you want is to select based on the <architecture> feature. Something like:
if ! [ feature.get-values architecture : $(condition) ] in ia64 || [ feature.get-values python : $(condition) ] in 1.5 1.6 2.0 2.1 2.2 2.3 2.4 { suffix = sl ; } else { suffix = so ; }
I notice though that we don't have pa-risc in the set of architectures:
# Type of CPU architecture to compile for. feature architecture : # x86 and x86-64 x86 # ia64 ia64 # Sparc sparc # RS/6000 & PowerPC power # MIPS/SGI mips1 mips2 mips3 mips4 mips32 mips32r2 mips64 # : propagated optional ;
I can add in "hppa" or "parisc". Or do you prefer something else? Similar question for the instruction-set feature. I can add in "pa-risc-1-0", "pa-risc-1-1", and "pa-risc-2-0". Or do you prefer a different nomenclature?
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Mon Nov 19 2007, "Boris Gubenko" <Boris.Gubenko-AT-hp.com> wrote:
Rene Rivera wrote:
Looking at more of the context of python.jam what you want is to select based on the <architecture> feature. Something like:
if ! [ feature.get-values architecture : $(condition) ] in ia64 || [ feature.get-values python : $(condition) ] in 1.5 1.6 2.0 2.1 2.2 2.3 2.4 { suffix = sl ; } else { suffix = so ; }
I can use '! [ feature.get-values architecture : $(condition) ] in ia64' or I can use '[ os.platform ] != IA64' (I tested the latter during the weekend). Which one is preferable?
Whichever is appropriate for your use case. The former represents the target architecture of the compiler and the latter represents the OS that bjam is being run on. I suspect you want the former. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Mon Nov 19 2007, "Boris Gubenko" <Boris.Gubenko-AT-hp.com> wrote:
Rene Rivera wrote:
Looking at more of the context of python.jam what you want is to select based on the <architecture> feature. Something like:
if ! [ feature.get-values architecture : $(condition) ] in ia64 || [ feature.get-values python : $(condition) ] in 1.5 1.6 2.0 2.1 2.2 2.3 2.4 { suffix = sl ; } else { suffix = so ; } I can use '! [ feature.get-values architecture : $(condition) ] in ia64' or I can use '[ os.platform ] != IA64' (I tested the latter during the weekend). Which one is preferable?
Whichever is appropriate for your use case. The former represents the target architecture of the compiler and the latter represents the OS that bjam is being run on. I suspect you want the former.
I guess I wasn't clear... Using "architecture" in this case is preferred because it is operating on a build product. To allow for cross-compiles it is not advisable to rely on system runtime values like '[ os.platform ]'. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Testing of [ feature.get-values architecture : $(condition) ] in ia64 on HP-UX ia64 and PA-RISC revealed that it evaluates to TRUE on both architectures. What could be the reason? Thanks, Boris ----- Original Message ----- From: "Rene Rivera" <grafikrobot@gmail.com> To: <boost@lists.boost.org> Sent: Monday, November 19, 2007 10:54 AM Subject: Re: [boost] [python] patch for python.jam for setting suffix onHP-UX
David Abrahams wrote:
on Mon Nov 19 2007, "Boris Gubenko" <Boris.Gubenko-AT-hp.com> wrote:
Rene Rivera wrote:
Looking at more of the context of python.jam what you want is to select based on the <architecture> feature. Something like:
if ! [ feature.get-values architecture : $(condition) ] in ia64 || [ feature.get-values python : $(condition) ] in 1.5 1.6 2.0 2.1 2.2 2.3 2.4 { suffix = sl ; } else { suffix = so ; } I can use '! [ feature.get-values architecture : $(condition) ] in ia64' or I can use '[ os.platform ] != IA64' (I tested the latter during the weekend). Which one is preferable?
Whichever is appropriate for your use case. The former represents the target architecture of the compiler and the latter represents the OS that bjam is being run on. I suspect you want the former.
I guess I wasn't clear... Using "architecture" in this case is preferred because it is operating on a build product. To allow for cross-compiles it is not advisable to rely on system runtime values like '[ os.platform ]'.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris Gubenko wrote:
Rene Rivera wrote:
I notice though that we don't have pa-risc in the set of architectures: [...] I can add in "hppa" or "parisc". Or do you prefer something else? Similar question for the instruction-set feature. I can add in "pa-risc-1-0", "pa-risc-1-1", and "pa-risc-2-0". Or do you prefer a different nomenclature?
Thank you for the proposal! I think, "parisc" as an architecture is fine. For now, we can test PA-RISC as not ia64, but what if HP-UX is ported to a different architecture? :-)
As for the instruction-set, I'm not sure how it is used. Why would we need "pa-risc-1-0", pa-risc-1-1" and "pa-risc-2-0" instead of a single name?
Hm... Never mind I read the wrong docs in GCC :-( If I'm reading the gcc docs correctly now, instruction-set would need: 700, 7100, 7100lc, 7200, 7300, and 8000. Which matches the -mschedule option possible values.
Also, while we are at it: can we define OSPLAT for PA-RISC in jam.h:
# if defined( __hpux ) && defined( __hppa ) # define OSPLAT "OSPLAT=PARISC" # endif
If there are no objections, I can make this change in the trunk.
Sure. But why check "__hpux"? Would it not be possible to run a different OS on a parisc? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
[...] instruction-set would need: 700, 7100, 7100lc, 7200, 7300, and 8000. Which matches the -mschedule option possible values.
Ok, thanks.
Sure. But why check "__hpux"? Would it not be possible to run a different OS on a parisc?
I guess, it is possible. I'll drop __hpux. Thanks again, Boris ----- Original Message ----- From: "Rene Rivera" <grafikrobot@gmail.com> To: <boost@lists.boost.org> Sent: Monday, November 19, 2007 11:13 AM Subject: Re: [boost] [python] patch for python.jam for setting suffix onHP-UX
Boris Gubenko wrote:
Rene Rivera wrote:
I notice though that we don't have pa-risc in the set of architectures: [...] I can add in "hppa" or "parisc". Or do you prefer something else? Similar question for the instruction-set feature. I can add in "pa-risc-1-0", "pa-risc-1-1", and "pa-risc-2-0". Or do you prefer a different nomenclature?
Thank you for the proposal! I think, "parisc" as an architecture is fine. For now, we can test PA-RISC as not ia64, but what if HP-UX is ported to a different architecture? :-)
As for the instruction-set, I'm not sure how it is used. Why would we need "pa-risc-1-0", pa-risc-1-1" and "pa-risc-2-0" instead of a single name?
Hm... Never mind I read the wrong docs in GCC :-( If I'm reading the gcc docs correctly now, instruction-set would need: 700, 7100, 7100lc, 7200, 7300, and 8000. Which matches the -mschedule option possible values.
Also, while we are at it: can we define OSPLAT for PA-RISC in jam.h:
# if defined( __hpux ) && defined( __hppa ) # define OSPLAT "OSPLAT=PARISC" # endif
If there are no objections, I can make this change in the trunk.
Sure. But why check "__hpux"? Would it not be possible to run a different OS on a parisc?
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Boris Gubenko -
David Abrahams -
Rene Rivera -
Stefan Seefeld