[Numpy-discussion] [ANN] numscons 0.3.0 release

[David Cournapeau]

Charles R Harris wrote:
>
>
> On Jan 25, 2008 3:21 AM, David Cournapeau 
> <david at ar.media.kyoto-u.ac.jp <mailto:david at ar.media.kyoto-u.ac.jp>> 
> wrote:
>
>     Matthew Brett wrote:
>     > Hi David,
>     >
>     >>> Basically, I'm trying to understand the library discovery, linking
>     >>> steps - ATLAS in particular.
>     >> Don't trust the included doc: it is not up-to-date, and that's
>     the part
>     >> which I totally redesigned since I wrote the initial doc.
>     >
>     >>     - For a perflib check to succeed, I try to compile, link
>     and run
>     >> code snippets. Any failure means the Check* function will
>     return failure.
>     >>     - When a perflib Check* succeeds, the meta library check
>     checks that
>     >> another code snippet can be compiled/linked/run.
>     >
>     > Thanks - and I agree, for all the reasons you've given in later
>     emails
>     > that this seems like the way to go.
>     >
>     > But, in the mean time, I've got problems with the perflib stuff.
>     > Specifically, the scons build is not picking up the atlas
>     library for
>     > blas and lapack that works for the standard build.  I'm on a 64 bit
>     > system, providing an extra layer of complexity.
>     I have never tested the thing on 64 bits (I don't have easy access
>     to 64
>     bits machine, which should change soon, hopefully), so it is not
>     surprising it does not work now. I have taken this into account
>     for the
>     design, though (see below).
>     >
>     > I've attached the build logs.  I noticed that, for atlas, you check
>     > for atlas_enum.c - but do you in fact need this for the build?
>     Now. I just wanted one header specific to atlas. It looks like not all
>     version of ATLAS install this one, unfortunately (3.8, for example).
>     > numpy.distutils seemed to be satisfied with cblas.h and clapack.h in
>     > /usr/local/include/atlas.  It's no big deal to copy it from sources,
>     > but was there a reason you chose that file?
>     No reason, but it cannot be cblas.h (it has to be atlas specific;
>     otherwise, it does not make sense). The list of headers to check
>     can be
>     empty, though.
>     >
>     > The test for linking to blas and lapack from atlas fails too -
>     is this
>     > a false positive?
>     Hmm, if atlas check does not work, it sounds like a right negative
>     to me
>     :) If ATLAS is not detected correctly, it won't be used by blas/lapack
>     checkers. Or do you mean something else ?
>     >
>     > For both numpy.distutils and numpyscons, default locations of
>     > libraries do not include the lib64 libraries like /usr/local/lib64
>     > that us 64 bit people use.  Is that easy to fix?
>     Yes, it is easy, in the sense that nothing in the checkers code is
>     harcoded: all the checks internally uses BuildConfig instances,
>     which is
>     like a dictionary with default values and a restricted set of keys
>     (the
>     keys are library path, libraries, headers, etc...). Those BuildConfig
>     instances are created from a config file (perflib.cfg), and should
>     always be customizable from site.cfg
>
>     The options which can be customized can be found in the perflib.cfg
>     file. For example, having:
>
>     [atlas]
>     htc =
>
>     in your site.cfg should say to CheckATLAS to avoid looking for
>     atlas_enum.h
>
>     To make 64 bits work by default is a bit more complicated. I thought a
>     bit about the problem: that's why the checkers do not use BuildConfig
>     instances directly, but request them through a BuildConfigFactory. One
>     problem is that I don't understand how 64 bits libraries work; more
>     precisely, what is the convention of library path ? Is there a
>     lib64 for
>     each lib directory (/lib64, /usr/lib64, /usr/local/li64) ? Should the
>     standard ones (/lib, /usr/lib) checked at all, after the 64 bits
>     counterpart ?
>
>  
> It varies with the Linux distro. The usual convention (LSB, I think) 
> uses /usr/local/lib64, but Debian and distros derived from Debian use 
> /usr/local/lib instead. That's how it was the last time I checked, 
> anyway. I don't know what Gentoo and all the others do.
Grrr, that's annoying. Do you know any resource which has clear 
explanation on that ? (reading LSB documents do not appeal much to me, 
and I would only do that as a last resort).

cheers,

David