[Pythonmac-SIG] setup.py for Numeric/Numarray
bob at redivi.com
Mon Nov 22 23:37:23 CET 2004
1) Apple can't (or rather, won't ever) change their framework location.
2) Darwin might be Darwin and not Mac OS X, which won't have vecLib.
3) Checking for both is silly, because you won't reasonably ever have
the path to vecLib on a non-Darwin platform.. and if you somehow do,
it'll probably work anyway.
I can give more flexible code with regard to locating frameworks in an
identical manner to what gcc and dyld do, but that is only going to be
applicable if you work at Apple, or you are building against an SDK,
neither of which happen very often in practice. With regard to
building against a SDK, the API used by Numeric that is provided by
vecLib isn't going to change, ever, unless Numeric wants more stuff
that is provided only in OS X 10.4+, for example. This would be an
issue when and if it happens, but in that case you would probably link
against the NEW name (Accelerate.framework). I'm not sure if the
vecLib API is supported by OS X 10.1, but someone else is going to have
to care about that because I sure don't.
Alternate linkers isn't really a concern because the three command-line
compilers that matter probably all support the -framework flag.
Apple's GCC (obviously..) and IBM's XLC (according to Robert) certainly
do, and more likely than not, MetroWerks CodeWarrior also does (someone
else would have to confirm this). If Fink or Gentoo ships some purely
GNU-based compiler/linker that doesn't support -framework, I'd consider
that a bug. I'm not sure how they'd get many things to compile
correctly without it, unless they're emulating it by specifying paths
directly to the Mach-O MH_DYLIB files
(/System/Library/Frameworks/vecLib.framework/vecLib, for example) PLUS
using non-framework-style header paths everywhere, since
<vecLib/vecLib.h> would never work if you -I to anywhere in the
framework tree. Does an unpatched GNU toolchain even understand Mach-O
in the first place? Most likely a non-issue in any case, but I'm not
about to Finkify any machine to test that theory.
In summary, I wrote the patch in that way for the specific reason of
doing it as correctly as possible without overcomplicating things. I
hope that people would trust that I know what I'm doing.
[not cross-posted because the message I'm replying to isn't
cross-posted, too lazy to figure out where it should be CC'ed to]
On Nov 22, 2004, at 10:08 PM, Chris Barker wrote:
> Hi all,
> Bob's patch to the Numeric setup.py made it's way to the numaray CVS,
> and there is a little discussion about improvements. I really don't
> know what to say but if some if the OS-X experts (Bob and Jack,
> anyway!) on this list could weigh in, the would be great. Here is a
> consolidation of the thread:
> Andrea Riciputi wrote:
>> I've noticed your patch for MacOS X, and I think that a better
>> solution should use sys.platform instead of a path search, since
>> Apple could always change its framework location. I've also removed
>> the VECLIB_PATH/Headers from the include path because AFAIK Apple
>> gcc already knows where to search for the vecLib framework. Here it
>> is a diff output between my addons.py and the CVS one.
> <trimmed by me: chb>
>>> ! if sys.platform == "darwin":
>>> ! lapack_include_dirs =
>>> - lapack_link_args = ['-framework', 'vecLib']
>>> ! VECLIB_PATH = '/System/Library/Frameworks/vecLib.framework'
>>> ! if os.path.exists(VECLIB_PATH):
>>> ! lapack_link_args = ['-framework', 'vecLib']
>>> ! lapack_include_dirs.append( os.path.join(VECLIB_PATH,
>>> lapack_libs = 
>>> lapack_dirs = 
> Todd Miller wrote:
>> Not to look a patch-horse in the mouth, but IMHO, the sys.platform
>> is good but the VECLIB_PATH elimination maybe less so. The reason I
>> question the VECLIB_PATH change is that we're removing explicit and
>> generally harmless extra information in exchange for two assumptions:
>> (1) gcc knows the path already (2) the numarray Mac user is using
>> gcc. Other opinions? Mac users please speak up if you think the
>> change is a good one or it won't get done.
> Andrea Riciputi wrote:
>> I see your point but AFAIK the links option "-framework vecLib" will
>> work *only* with Apple gcc (ld) and Apple gcc (ld) does know where
>> frameworks are. From Apple ld man page:
>>> -framework name[,suffix]
>>> Specifies a framework to link against. Frameworks are dynamic
>>> shared libraries, but they are stored in different locations,
>>> and therefore must be searched for differently. When this option
>>> is specified, ld searches for framework `name.framework/name'
>>> first in any directories specified with the -F option, then in
>>> the standard framework directories /Library/Frameworks, /Net-
>>> work/Library/Frameworks, and /System/Library/Frameworks. The
>>> placement of the -framework option is significant, as it deter-
>>> mines when and how the framework is searched. If the optional
>>> suffix is specified the framework is first searched for the name
>>> with the suffix and then without.
>>> In Apple's version of GCC only, add the directory dir to the head
>>> of the list of directories to be searched for frameworks.
>>> The framework search algorithm is, for an inclusion of
>>> <Fmwk/Header.h>, to look for files named
>>> ers/Header.h or path/Fmwk.framework/PrivateHeaders/Header.h where
>>> path includes /System/Library/Frameworks/ /Library/Frameworks/,
>>> /Local/Library/Frameworks/, plus any additional paths specified
> Robert Kern wrote:
>> IBM's xlc will also find the appropriate framework, but as you can
>> see this is only a link-time option and has nothing to do with
>> finding headers.
>> #include <vecLib/vecLib.h>
>> will find the appropriate header without any command-line options.
>> #include <clapack.h>
>> will not.
>> Fortunately, neither one is used nor needed by lapack_litemodule.c,
>> so for this case, no include-path needs to be specified.
> If you don't want to post tot he NumPy list directly, I'd be glad to
> forward comments on.
> Christopher Barker, Ph.D.
> NOAA/OR&R/HAZMAT (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
> Chris.Barker at noaa.gov
> Pythonmac-SIG maillist - Pythonmac-SIG at python.org
More information about the Pythonmac-SIG