Replacement for numpy.distutils.config.try_run
Hi, In distutils/config.py line 32 I see: "Usage of try_run is deprecated: please do not \n" \ "use it anymore, and avoid configuration checks \n" \ "involving running executable on the target machine.\n" \ What is the recommended way of doing configuration checks now? Regards Stéfan
Stéfan van der Walt wrote:
Hi,
In distutils/config.py line 32 I see:
"Usage of try_run is deprecated: please do not \n" \ "use it anymore, and avoid configuration checks \n" \ "involving running executable on the target machine.\n" \
What is the recommended way of doing configuration checks now?
It only refers to try_run kind of checks (that is when you need to run an executable on the machine). I added this when I had some problems running it on windows 64 bits with python 2.6 - According to Martin Loewis, try_run was not supposed to work everywhere, in particular in cross-compilation contexts (which is relatively current for windows in the context 32 vs 64 vs itanium). It happened that in that particular case where it is used in numpy, I found a way around it, but I would like to get rid of it completely at some point. David
2009/1/9 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
It happened that in that particular case where it is used in numpy, I found a way around it, but I would like to get rid of it completely at some point.
What do you suggest as workarounds? Stéfan
Stéfan van der Walt wrote:
2009/1/9 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
It happened that in that particular case where it is used in numpy, I found a way around it, but I would like to get rid of it completely at some point.
What do you suggest as workarounds?
What about not using tests which need to run on the target platform :) It is not always easy, but in numpy cases, it is simple, at least principle (numscons build does not run any test code, for example): try_run is used to check whether some preprocessor defined are available (see numpy/random and numpy/core), which is not necessary. The autobook specifically mentions that code which need to run on target platforms should be avoided, since it breaks cross-compilation; with python distutils, it exactly breaks in those cases. cheers, David
2009/1/9 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
What do you suggest as workarounds?
What about not using tests which need to run on the target platform :)
Let me simplify the question. How do you detect the version of the local Fortran compiler without executing the compiler? Or is that OK, and you'd simply like to avoid compiling and running code? Stéfan
Stéfan van der Walt wrote:
2009/1/9 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
What do you suggest as workarounds?
What about not using tests which need to run on the target platform :)
Let me simplify the question. How do you detect the version of the local Fortran compiler without executing the compiler? Or is that OK, and you'd simply like to avoid compiling and running code?
Ah, sorry, I used the autotools vocabulary you may not be familiar with: when cross compiling, you have at least two platforms, build and host/target (host/target is the same unless you build cross-compilers). If I build foobar on linux for windows, linux is the build, windows the host/target. Anything which runs on the host/target platform cannot work in this context; anything on the build of course can - which generally includes compilers, etc... Basically, assuming a working compiler, pre-processing, compiling, linking test code snippets is OK. Running is not. cheers, David
On Fri, Jan 9, 2009 at 02:31, Stéfan van der Walt <stefan@sun.ac.za> wrote:
2009/1/9 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
What do you suggest as workarounds?
What about not using tests which need to run on the target platform :)
Let me simplify the question. How do you detect the version of the local Fortran compiler without executing the compiler?
try_run() is not the right thing to call for such a purpose. Use FCompiler.get_version(). -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
2009/1/9 Robert Kern <robert.kern@gmail.com>:
try_run() is not the right thing to call for such a purpose. Use FCompiler.get_version().
That was just an example. What I want to do is run something like "pkg-config blah" and parse the output, but I get the idea from David's post that that is OK. Cheers Stéfan
On Fri, Jan 9, 2009 at 03:27, Stéfan van der Walt <stefan@sun.ac.za> wrote:
2009/1/9 Robert Kern <robert.kern@gmail.com>:
try_run() is not the right thing to call for such a purpose. Use FCompiler.get_version().
That was just an example. What I want to do is run something like "pkg-config blah" and parse the output, but I get the idea from David's post that that is OK.
But that's not what try_run() does. Use exec_command() for general purpose running of programs. try_run() compiles a program from source and runs the result. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
participants (3)
-
David Cournapeau -
Robert Kern -
Stéfan van der Walt