Hi, After more investigation, I found that there already exist a way to suppress those message on posix system. So I reused it in the PR. That way, it was faster, but prevent change in that area. So there is less change of breaking other syste:
https://github.com/numpy/numpy/pull/4081 But it remove the stdout when we run this command: numpy.distutils.system_info.get_info("blas_opt") But during compilation, we still have the info about what is found: atlas_blas_threads_info: Setting PTATLAS=ATLAS Setting PTATLAS=ATLAS customize Gnu95FCompiler Found executable /usr/bin/gfortran customize Gnu95FCompiler customize Gnu95FCompiler using config compiling '_configtest.c': /* This file is generated from numpy/distutils/system_info.py */ void ATL_buildinfo(void); int main(void) { ATL_buildinfo(); return 0; } C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -fPIC compile options: '-c' gcc: _configtest.c gcc -pthread _configtest.o -L/usr/lib64/atlas -lptf77blas -lptcblas -latlas -o _configtest success! removing: _configtest.c _configtest.o _configtest Setting PTATLAS=ATLAS FOUND: libraries = ['ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/usr/lib64/atlas'] language = c define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] include_dirs = ['/usr/include'] FOUND: libraries = ['ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/usr/lib64/atlas'] language = c define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] include_dirs = ['/usr/include'] non-existing path in 'numpy/lib': 'benchmarks' lapack_opt_info: lapack_mkl_info: mkl_info: libraries mkl,vml,guide not found in ['/opt/lisa/os_v2/common/Canopy_64bit/User/lib', '/usr/local/lib64', '/usr/local/lib', '/usr/lib64', '/usr/lib'] NOT AVAILABLE NOT AVAILABLE atlas_threads_info: Setting PTATLAS=ATLAS libraries ptf77blas,ptcblas,atlas not found in /opt/lisa/os_v2/common/Canopy_64bit/User/lib libraries lapack_atlas not found in /opt/lisa/os_v2/common/Canopy_64bit/User/lib libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib64 libraries lapack_atlas not found in /usr/local/lib64 libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib libraries lapack_atlas not found in /usr/local/lib libraries lapack_atlas not found in /usr/lib64/atlas numpy.distutils.system_info.atlas_threads_info Setting PTATLAS=ATLAS Setting PTATLAS=ATLAS FOUND: libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/usr/lib64/atlas'] language = f77 define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] include_dirs = ['/usr/include'] FOUND: libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/usr/lib64/atlas'] language = f77 define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] include_dirs = ['/usr/include'] Frédéric On Fri, Nov 22, 2013 at 4:26 PM, Frédéric Bastien <[email protected]> wrote: > I didn't forgot this, but I got side tracked. Here is the Theano code > I would like to try to use to replace os.system: > > https://github.com/Theano/Theano/blob/master/theano/misc/windows.py > > But I won't be able to try this before next week. > > Fred > > On Fri, Nov 15, 2013 at 5:49 PM, David Cournapeau <[email protected]> wrote: >> >> >> >> On Fri, Nov 15, 2013 at 7:41 PM, Robert Kern <[email protected]> wrote: >>> >>> On Fri, Nov 15, 2013 at 7:28 PM, David Cournapeau <[email protected]> >>> wrote: >>> > >>> > On Fri, Nov 15, 2013 at 6:21 PM, Charles R Harris >>> > <[email protected]> wrote: >>> >>> >> Sure, give it a shot. Looks like subprocess.Popen was intended to >>> >> replace os.system in any case. >>> > >>> > Except that output is not 'real time' with straight Popen, and doing so >>> > reliably on every platform (cough - windows - cough) is not completely >>> > trivial. You also have to handle buffered output, etc... That code is very >>> > fragile, so this would be quite a lot of testing to change, and I am not >>> > sure it worths it. >>> >>> It doesn't have to be "real time". Just use .communicate() and print out >>> the stdout and stderr to their appropriate streams after the subprocess >>> finishes. >> >> >> Indeed, it does not have to be, but that's useful for debugging compilation >> issues (not so much for numpy itself, but for some packages which have files >> that takes a very long time to build, like scipy.sparsetools or bottleneck). >> >> That's a minor point compared to the potential issues when building on >> windows, though. >> >> David >> >> _______________________________________________ >> NumPy-Discussion mailing list >> [email protected] >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
