[Pythonmac-SIG] setup.py for Numeric/Numarray
mww at opendarwin.org
Wed Nov 24 01:36:44 CET 2004
On Nov 22, 2004, at 23:37, Bob Ippolito wrote:
> Two things:
> 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.
this is a mistake that I see quite often:
implying MacOS-X or just PPC from "darwin"
I have to second Bob on that one - please don't do that!
It's quite a pain to fix this kind of bugs so stuff will work on
OpenDarwin or even OpenDarwin/x86;
> 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 VECLIB_PATH
>>> 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
>>>> 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
>>>> 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
> Pythonmac-SIG maillist - Pythonmac-SIG at python.org
Markus W. Weissmann
More information about the Pythonmac-SIG